SERVICE  ElMGiNEERING  REPORT 

FOR 

F411  SIMULATION  STUDY 

, (FINAL  REPp8T)r 

I 28  Novimbar  5973  ~i  (^:  >/-  , 


Prepared  for  SMAMA  irt  Accordance  With 
Contract  F04G06-73  D-0141 J Task  007 

( / 


Prepared  by 
P.S.  Hodges 


' D D C' 

Uj  „„ 


JUL  22  1977 

MOTITE 


Autonetics  Division 

Rockwell  International 


3370  Miraloma  Avenue.  Anaheim.  California  92803 


FOREWORD 


'^This  study  was  performed  by  Rockwell  International’s  Autonetics  Division  for 
the  Sacrame^p  Air  Material  Area  (SMAMA)  as  a task  within  the  scope  of  Air  Force 
Contract  F04^-73-D-014  1.  Ihe  purpose  of  the  study  was  to  investigate  the  need  and/or 
feasibility  of  a digitally  controlled  F-111  simulation  facility  at  SMANIA.  This  facility 
would  provide  SMAMA  with  the  capability  to: 

Q ' I ' - 'o ^ j 

^ 1.  Verify  and  validate  prior  to  flight  test 


>2.  Investigate  problems/changes 


. r- 


3.  Formulate  and  checkout  solutions  to  problems# 

These  capabilities  will  be  required  in  order  for  SMAMA  to  satisfy  their  AF  Engineer-  j 

ing  responsibility  for  F-lllD,  FB-lllA  and  F-lllF  flight  tapes.  I 

I 

This  report  contains  the  answers  to  specific  questions  that  were  asked  by 
SMAMA.  Additionally,  it  describes  a simulation  approach  that  will,  when  imple- 
mented, provide  the  desired  capability.  This  approach  is  one  of  many  that  could  be 
taken,  and  is  based  strongly  on  a concept  of  providing  a satisfactory  initial  capability 
that  can  be  expanded  or  modified  during  the  F-111  operational  lifetime.  The  areas  of 
expansion  are  also  discussed  in  the  report. 
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1.  INTRODUCTION 


1.1  ORGANIZATION 

This  report  is  organized  in  general  accordance  with  Data  Item  Description 
I^I“S-360l/S-142-l,  Service  Engineering  Reports,  as  required. 

1.2  CONTENT 

Sections  2,  3 and  4 consist  of  summary  study  results  and  background  informa- 
tion describing  the  need  for  the  study. 

The  majority  of  the  detailed  information  derived  during  the  study  is  presented 
in  Section  5.  This  includes:  (1)  conceptual  configurations  of  both  hardware  and 
software  baseline  approaches  recommended  by  Autonetics  with  potential  growth  and 
alternate  uses  of  the  recommended  facility;  (2)  presentation  of  a realistic  development 
program,  including  schedules  and  an  estimate  of  cost/manpower  required  to  obtain 
the  facility  and  (3)  rationale  substantiating  the  need  for  and  benefits  to  be  derived 
from  such  a facility. 

Section  6 presents  the  study  conclusions  and  recommendations  for  specific 
future  actions  to  be  taken  by  SMAMA,  Sections  7 and  8 present  references  and 
abbreviations  used  in  the  report. 


2.  SUMMARY 


2.1  GENERAL 

The  study  as  conducted  by  Autonctics  consisted  of  two  primary  efforts.  The 
first  was  an  investigation  into  the  existing  capability  of  SMAMA  to  produce  the 
required  operational  software  and  system  level  support  with  existing  support  equip- 
ment. The  second  was  preparation  of  a conceptual  definition  for  a dynamic  simulator 
to  be  used  in  Operational  Flight  fVogram  (OFF)  checkout  and  evaluation. 

Both  of  these  efforts  were  predicated  on  the  following  factors  that  are  identified 
here  for  continuity:  (1)  SMAMA,  having  had  little  previous  active  participation  in 
F-111  OFF  preparation  and  checkout,  will  be  required  to  provide  a minimum  of  one 
flight  tape  per  year  for  each  of  the  three  F-111  configurations,  (2)  Available  checkout 
facilities  consist  of  the  MARK  II  Integration  Test  Equipment  (ITf')  and  the  F-111  nose- 
bay  mockups,  (3)  the  OFF  responsibility  will  continue  through  the  life  of  the  F-111 
program,  considered  for  the  purpose  of  this  study  to  be  approximately  ten  years, 
and  (4)  OFF  checkout  consists  of  ground  evaluation  (presently  using  the  ITE),  followed 
by  flight  test  at  SMAMA  and  finally,  flight  evaluation  by  the  using  commands. 

The  ITE  and  nose-bay  mockups  provide  the  capability  to  operate  the  various 
F-111  avionics  subassemblies.  This  test  equipment,  while  satisfying  the  purpose  for 
which  it  was  intended,  is  inadequate  for  a long-term,  software  maintenance/dcvelop- 
mbnt  program. 

The  apparent  heavy  emphasis  placed  on  "simulation"  could  be  misleading  to  the 
reader.  In  actuality  the  main  thrust  of  the  study  was  to  define  an  integrated,  dynamic, 
software  test/verification  facility.  The  purpose  of  the  simulation  is  to  provide  a 
realistic,  dynamic  environment  in  which  detailed  test  and  evaluation  of  F-111  softw'are 
and  software/hardware  combination  can  be  accomplished.  'This  test  and  evaluation 
Is  Implemented  through  use  of  the  real-time  data  monitoring  and  control  devices 
Included  with  the  dynamic  simulation.  In  this  light,  the  facility  recommended  in  this 
report  could  be  considered  as  an  F-111  Simulation/Integration  Test  Station  (SITS). 

2.2  RESULTS  OF  FRIMARY  EFFORTS 

Following  subparagraphs  summarize  the  results  of  the  two  primary  study 
efforts. 

2.2.1  Existing  Capability  Evaluation 

One  goal  of  this  study  was  to  determine  if  existing  test  facilities  and  maintenance 
procedures  are  adequate  to  provide  required  software  and  system  level  support. 
Factors  considered  in  this  study  were:  (1)  the  expected  level  of  flight  tape  mainte- 
nance, (2)  past,  present  and  e.xpected  software/system  problems,  (3)  the  test  capabil- 
ities of  the  static  integration  test  facilities  (ITE)  and  (4)  the  debugging/ troubleshooting 
effectiveness  of  past  F-111  flight  test  programs.  Investigation  revealed  that  the 
existing  test  facility  and  software  maintenance  approach  is  inadequate  and  is  not  cost 
effective.  Ferhaps  more  importantly,  complete  dependence  on  this  facility  could 
result  in  failure  to  achieve  the  complete  potential  of  the  FB-lllA,  F-lllD  and  F-lllF 
weapon  systems.  It  was  determined  that  an  operator  oriented  dynamic  tcsi/simulatlon 
facility  designed  for  the  purpose  of  identifying,  investigating  and  solving  software 
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problems  is  required  to  meet  the  F-111  operationnl  flight  program/system  level 
maintenance  requirements.  This  facility  would  provide  for:  (1)  timely  solutions  to 
field  problems  or  new  requirements,  (2)  a reduction  of  up  to  50  percent  in  the  total 
amount  of  flight  testing  and  (3)  realization  of  the  complete  potential  of  the  F-lll 
digital  avionic  system. 

Autoneties  completed  tlie  first  FU-lllA  tape  program  in  1967  and  the  first  F-lllD 
tape  in  1968.  During  the  past  six  years,  there  have  been  eleven  tape  revisions  for  the 
FB  aircraft  and  seven  for  the  D.  These  revisions,  primarily  oriented  at  problem 
solving,  consumed  almost  monumental  software  effort  by  Autoneties,  GD/l-VV  and 
USAF.  This  effort  was  expended  by  personnel  who  were  intimately  familiar  with  the 
programs/systems  by  virtue  of  the  fact  that  thej’  developed  and/or  worked  with  the 
programs  for  an  extensive  period  of  time.  In  spite  of  this  effort,  approximately 
150  open  items,  including  apparent  problems  and  enhancements,  will  remain  in  the 
SMAMA  F-lll  Problem  Book  after  approval  of  the  baseline  tapes.  Clearly,  the 
methods  and  techniques  used  for  the  OFP  checkout  and  verification  have  been 
Inadequate. 

Highlights  of  the  evaluation  of  existing  capability  are  presented  below.  A more 
detailed  discussion  of  this  evaluation  is  presented  in  Section  5.6. 

2.2. 1. 1 Test  Equipment 

The  existing  (static)  ITE  was  found  not  to  be  software  checkout  oriented.  This 
equipment  was  designed  for  system  integration/checkout  by  contractor  personnel  who 
had  intimate  knowledge  of  the  detailed  system  mechanization.  As  such  this  equipment 
has  limited  signal  control,  lack  of  data  monitoring  or  data  gathering  capability  and 
no  ability  to  create  a controlled  dynamic  program  environment  necessary  for  problem 
solving. 

The  process  of  software  problem  isolation/solution,  flight  program  debugging 
and  system  hardware  evaluation  requires  the  capability  to  monitor  program  operation 
and  obtain  data.  The  existing  ITE  has  no  real-time  data  gathering  capability.  Criti- 
cal interfaces  such  as  exist  between  the  computers  and  converter  cannot  be  examined. 
The  computer  cannot  be  monitored  during  tests  to  provide  answers  to  flight  program 
problems.  Total  serial  data  transfer  over  the  subsystem  Interfaces  cannot  be  dynam- 
ically monitored  and  analyzed. 

The  majority  of  F-lll  flight  computer  subprograms  involve  a dynamic,  inter- 
active process.  Other  than  for  static  mode  and  control  logic  functions,  the  flight 
programs  operate  on  dynamically  changing  input  signals.  Computations  for  navigation, 
weapon  delivery  and  steering  involve  dynamic  data  sensors  such  as  the  inertial  plat- 
form, attack  radar,  doppler  radar,  air  data  computer,  etc.  The  existing  ITE  facili- 
ties cannot  exercise  these  sensors  dynamically  to  simulate  actual  flight  conditions. 

This  deficiency  limits  solution  of  a large  number  of  F-lll  flight  problems  and  is 
discussed  briefly  in  Section  5.6,  relative  to  existing,  known  problems. 

2. 2. 1.2  Computer  Utilization 

The  F-lll  flight  programs  were  found  to  utilize  98  to  100  percent  of  the  available 
computer  memory  and  cycle  times.  Individual  changes  to  these  highly  efficient 
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flight  programs  resulted  in  an  interaction  throughout  the  entire  flight  program.  U is 
virtually  impossible  to  make  a progr.am  eharige  without  affecting  other  areas  of  the 
OFP.  Existing  test  equipment  does  not  provide  tlie  visibility  to  determine  these 
interactions. 

2. 2. 1.3  Air  Force  F-111  OFP  Experience 

Detailed  Air  Force  involvement  in  the  preparation  and  development  of  F-111 
flight  programs  was  virtually  non-existent.  Little  knowledge  exists  of  the  details  of 
the  subprograms  and  the  rationale  behind  their  development  and/or  optimization. 
Problem  solving  requires  intimale  knowledge  of  the  flight  program.  A dynamic  test 
facility  can  provide  this  visibility  by  way  of  providing  both  dynamic  operating  condi- 
tions and  the  instrumentation  and  access  to  the  inner  workings  of  the  system/ 
software  while  in  those  conditions. 

An  attempt  by  AFLC/SMAMA  (or  other  organization  or  contractor)  to  perform 
the  F-111  operational  flight  programs  and  system  level  maintenance  tasks  with  these 
major  test  limitations  will  result  in  a costly  and  inadequate  maintenance  program.  A 
current  example  of  the  required  flight  program  validation  effort  can  be  seen  in  the 
F-lllD  flight  test  presently  being  conducted  at  Cannon  AFB.  Forty  sorties  are 
planned  for  flight  test  validation  of  the  recently  received  "final" F-11  ID  o|)orational 
flight  program  (tape  D07  115/215).  The  requirement  for  this  type  of  program,  being 
conducted  by  SMAMA,  SPO,  Cannon  and  contractor  personnel,  'is  based  on  experience 
gained  on  similar  programs  conducted  at  Mountain  Home  AFB.  Even  this  amount  of 
effort,  following  extensive  contractor  tape  proparation/checkout,  will  likely  leave 
numerous  uncertainties  in  the  readiness  of  the  flight  tape,  and  hence  the  weapon  sys- 
tem. Autonetics  estimates  that  dynamic  simulation  could  reduce  the  cost  of  sucli  a 
program  (for  single  tape  checkout)  by  half  a million  dollars,  and  result  in  substanti- 
ally Increased  confidence  in  the  OFP.  The  details  of  this  estimate,  along  with  other 
requirements  rationale,  are  presented  in  Section  5.6. 

2.2.2  F-111  Simulation/Integration  Test  System  (SITS)  Summary 

The  need  for  a dynamic  simulation  and  test  capability  was  summarized  in 
Section  2.2.1.  However,  the  architecture  of  such  a system  must  be  structured  to 
facilitate  problem  solution  and  operational  flight  program  updates  from  the  test 
operator's  standpoint.  Provision  should  exist  for  test  mission  profiles  to  be  flown 
with  full  test  operator  monitoring  and  sequence  control.  In  summa  ry,  it  must  be  an 
operator-controlled  simulation  system.  Moreover,  for  efficiency,  the  system  should 
provide  a high  degree  of  commonality  among  the  three  F-111  systems.  This  common- 
ality encompasses  interface  hardware,  test  software,  test  operator  procedures,  and 
growth  provisions.  The  system  approach  discussed  in  Section  5.2  satisfies  these 
commonality  and  operator-controlled  goals.  Figure  2-1  is  a simplified  block  diagram 
of  the  F-111  simulation  system  approach.  It  is  noted  that  the  relative  sizes  of  the 
'Interface  hardware" blocks  show  the  intent  of  satisfying  the  commonality  goal.  The 
next  few  paragraphs  indicate  some  of  the  major  features  of  the  approach. 

One  of  the  basic  features  allows  (for  the  first  time)  the  F-111  operational  flight 
programs  to  be  tested  and  verified  collectively.  There  is  no  'fcontamination"  of  the 
flight  programs  with  such  typical  add-ons  as  data  pumps  and  monitors.  These 
functions,  necessary  for  proper  monitoring  and  test  control,  are  performed  by 


Figure  2-1.  F-111  Simulation  System  General  Block  Diagram 


hardware  which  interfaces  with  the  internal  and  external  memory  and  data  buses  of 
the  computers.  Moreover,  the  test  operator,  via  the  test  computer  simulation 
system,  has  direct  control  over  these  bus  interface  units.  Therefore,  he  can  start, 
stop,  monitor,  skip  and  generally  'Walk"  the  simulation  system  through  almost  all 
sequence  steps. 

Another  major  feature  is  the  variety  of  interactive  devices  available.  The 
keyboards  provide  the  major  interface  with  the  test  system.  Using  the  various 
options,  the  test  operator  can,  as  a minimum: 

1.  Call  for  a menu  of  test  setups  and  select  the  desired  one 

2.  Call  for  test  setup  procedures  to  be  displayed  on  the  CRT(s) 

3.  Load  F-111  flight  programs  and  specific  changes  for  the  current  test  setup 

4.  Initialize  the  air  vehicle  dynamic  simulator  which  provides  the  real  world 
reference  for  F-111  test/evaluation 

5.  Identify  the  type  of  simulation  to  be  performed  (e.g. , canned  profile, 
static  under  keyboard  control,  system  operator  control  using  actual 
stick  and  throttle  inputs  to  the  real  world  air  vehicle  simulator) 

6.  Monitor  simulator  performance  on  CRT(s) 
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7.  Monitor  F-llI  pcrfonnance  on  CRT(s) 

8.  Record,  for  later  analysis,  both  simulator  and  P"-II1  parameters  on 
printers,  magnetic  tapes,  etc. 

These  options  and  more  pros  ide  the  test  operator  with  complete  flexibility  to 
simulate  the  actual  fUtdit  ens  ironnient.  He  can  then  reproduce  a problem,  establish 
possible  solutions,  and  st  cifs’  the  selected  solution  in  a dynamic  atmosphere  without 
necessitating  any  flight  tests.  The  same  interactive  devices  allow  him  to  evaluate 
new  modes,  functions,  weapons,  tactics,  etc. , with  the  realism  of  actual  flight 
conditions.  ° 


The  design  and  development  of  the  F-111  simulation  system  is  envisioned  in 
phases  Phase  1 would  provide  about  90  percent  of  the  total  dynamic  simulation 
capability.  Phases  2 and  3 would  add  subsystem  simulations  and  provide  for  expanded 
static  testing.  A realistic  Phase  1 schedule  has  been  estimated  at  eighteen  months 
wi  h an  assumed  go-ahead  of  January  1974.  Kstimated  rcsoui'ces  required  to  obtain 
such  lacilities  as  are  described  herein,  within  the  eighteen  month  schedule,  total 
approximately  285  manmonths  and  $590,  000.  This  investment  would  provide  both 
software  for  two  Simulation/Integration  Test  Stations  (F-lllD  and 
FB-lllA/F-lllF).  Details  of  the  development  including  estimated  cost  breakdown  are 
discussed  in  Section  5.5. 


The  proposed  simulation  system  is  responsive  to  the  need  for  testing  and 

programs.  The  test  philosophy  is  common  for  both  the 
F-lllD  and  FB-lllA/t  -IHF  configurations.  The  development  plan  and  schedule  is 
realistic  with  no  major  problems  envisioned. 


2-5, 


3.  STATEMENT  OF  THE  PROBLEM 


3.1  GENERAL 

The  F-111  Avionics  System  is  presently  in  a state  of  transition.  Contractor 
development  is  at  an  end  and  the  Air  Force  Systems  Command  is  turning  responsi- 
bility for  maintenance  engineering  over  to  the  Air  Force  Logistics  Command 
(AFLC/SMAMA).  The  avionics  hardware  and  software  could  be  supported  either  by 
the  contractor  or  organically.  Contractor  services  for  maintenance  engineering 
support  are  expensive  and  require  a high  degree  of  expertise  on  the  part  of  the  Air 
Force  to  properly  manage  the  contractor  efforts.  The  skills  needed  to  manage  the 
contract  are  similar  to  those  needed  to  actually  perform  the  work.  Therefore,  it  is 
in  the  best  interest  of  the  Air  Force  to  obtain  an  organic  capability  supplemented 
with  contractor  specialty  skills. 

The  maintenance  of  the  F-111  flight  programs  requires  the  use  of  special  tools 
developed  expressly  for  the  purpose.  At  present,  SMAMA  uses  only  the  Integration 
Test  Equipment  (ITE)  developed  by  Autonetics  during  the  early  phases  of  F-111  devel- 
opment for  integration  of  the  Mark  II  avionics.  This  equipment  is  a hot  mockup  of 
the  Mark  II  avionics  with  simulated  signals  which  can  be  manually  set  by  an  operator. 
Although  the  simulation  is  essentially  static,  it  is  dynamic  in  the  sense  that  aircraft 
velocity  is  an  input,  and  the  situation  originally  created  can  be  changed  by  the 
operator,  within  the  limits  of  manual  dexterity,  controlling  one  input  signal  at  a 
time.  The  equipment  has  severe  limitations,  and  cannot  provide  the  same  set  of 
time  varying  signals  that  an  aircraft  in  flight  would  present  to  the  avionic  system. 

In  the  future,  nosebay  mockups  and  subsystem  testers  will  be  addeu  to  the  support 
facility.  These  equipments  do  not  greatly  increase  the  ability  to  control  the  inputs 
or  provide  a more  realistic  set  of  input  signals. 

The  process  of  maintaining  the  operational  flight  programs  can  be  broken  into 
several  phases.  Each  phase  has  its  own  unique  requirements  for  support. tools.  The 
principal  phases  follow. 

3.1.1  Problem  Identification  and  Problem  Recreation 

One  of  the  first  steps  in  the  solution  of  any  problem  is  to  identify  the  complete 
set  of  symptoms  associated  with  a problem  and  to  recreate  the  situation  causing  the 
problem  at  will.  This  step  is  necessary  not  only  to  provide  the  necessary  foundation 
for  problem  resolution,  but  equally,  to  insure  that  tests  can  be  performed  to  verify 
the  correctness  of  a given  solution.  Tools  must  be  developed  which  exercise  the 
flight  program.  The  following  characteristics  must  be  provided. 

3. 1. 1. 1  Man  in  the  Loop 

Due  to  the  sketchy  descriptions  available  for  most  problems,  an  iterative 
process  is  necessary.  Initial  attempts  at  identifying  and  reproducing  problems  will 
be  highly  speculative,  with  successive  iterations  slowly  zeroing  in  on  the  problem 
area.  The  process  is  extremely  judgemental.  Such  characteristics  dictate  a very 
flexible  system  w'ith  a man  in  the  loop  if  the  length  of  each  iterative  cycle  is  to  be 
short  enough  to  allow  identification  of  the  problem  within  a reasonable  time. 
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In  order  to  exercise  an  area  of  code,  all  inputs  into  that  area  must  be  supplied. 
The  inputs  must  be  realistic  and  in  agreement  with  the  other  Inputs  being  supplied. 
Since  it  is  not  known  beforehand  which  areas  of  the  program  will  be  exercised,  pro- 
vision must  be  made  to  supply  every  input  to  the  Mark  II  system  in  a realistic  manner. 
As  an  example,  if  the  coefficients  of  the  Kalman  filter  were  being  checked,  inputs 
from  the  Inertial  Navigation  Set,  Central  Air  Data  Computer,  Auxiliary  Flight 
Reference  System,  J-Box,  Doppler  Radar  and  Astrocompass  (not  all  items  are  in 
every  aircraft  configuration)  must  be  provided.  Each  input  must  provide  the  correct 
stimulus  for  the  assumed  position  in  space  and  state  of  the  aircraft  (e.g. , inertial 
velocity  may  not  be  zero  with  a non-zero  system  velocity). 


3. 1.1. 3  Perturbated  Inputs 


Not  all  problems  are  caused  by  true  program  errors.  In  some  cases  the  pro- 
gram reaction  is  caused  because  the  inputs  are  not  as  ideal  as  was  assumed.  In 
order  to  investigate  such  problems,  control  of  equipment  failure,  noise,  bias,  and 
out  of  tolerance  signals  Is  required. 


3. 1.1.4  Repeatable  and  Controllable  Inputs  ' 

The  high  cost  of  software  maintenance  Is  primarily  attributable  to  the  cost  of 
skilled  personnel.  The  amount  of  time  spent  in  attempting  to  duplicate  a problem  can 
be  reduced  if  control  of  the  exercise  is  optimized  to  reduce  operator  setup  time. 
Another  problem  is  that  once  a problem  has  been  made  to  occur,  it  may  not  be  repro- 
duceable.  This  could  be  caused  either  by  the  fact  that  the  exact  analog  voltage  neces- 
sary cannot  be  reset  or  through  operator  oversight,  a switch  position  is  different  than 
the  first  time  the  problem  was  produced  in  the  laboratory.  Both  of  these  types  of 
problem  can  be  overcome  using  digital  techniques. 

3. 1. 1.5  Recording  and  Analysis 

The  use  of  various  recording  and  analysis  techniques  can  give  the  engineer  a 
significantly  larger  data  base  which  can  be  used  to  speed  the  analysis  of  a problem. 

3.1.2  Solution  Development 

Once  a problem  can  be  created  in  the  laboratory  and  a set  of  symptoms  found, 
various  engineering  analysis  techniques  can  be  used  to  formulate  trial  s^’.-lions. 
These  solutions  must  then  be  tested  in  the  flight  program  to  observe  the  correctness 
of  the  solution.  During  this  phase  of  program  development  the  effectiveness  of  an 
engineer's  time,  and  therefore,  program  maintenance  costs,  can  be  optimized  if  he 
has  tools  which  provide: 

3. 1.2.1  Alterability  of  the  Flight  Program 

The  ability  to  enter  changes  into  the  flight  program  for  analysis  purposes  is 
mandatory.  The  ability  to  do  this  without  Introducing  entry  errors  is  desirable  if 
time  and  equipment  are  to  be  used  effectively.  Using  the  present  computer  control 
panels  on  the  ITE,  if  an  address  is  entered  incorrectly,  the  change  can  be  entered 
Into  the  wrong  area  of  memory.  Later  attempts  to  locate  and  remove  the  erroneous 
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change  may  be  futile.  The  only  soUiticn  is  to  reload  the  computer  and  start  over. 

The  ability  to  chccU  the  information  before  it  is  loaded  is  therefore,  highly  desirable. 
This  can  be  done  when  changes  are  entered  under  the  control  of  another  computer. 

This  method  allows  easy  removal  of  a change  when  it  is  no  longer  de.sii'cd. 

3. 1.2.2  Documentation  Update  and  Configuration  Control 

The  use  of  automatic  recordi.'g  of  changes  provides  greater  confidence  that  the 
documentation  reflects  the  actual  flight  program  configuration.  It  eliminates  the 
possibility  that  someone  will  forget  to  document  the  entry  of  a change.  It  eliminates 
the  tedious  copying  of  changes  into  an  official  log  and  prevents  transcription  errors. 

It  also  provides  a convenient  method  of  maintaining  configuration  control. 

3.1.3  Testing 

Once  all  of  the  various  changes  have  been  developed,  they  are  all  entered  into 
the  flight  program  and  tested  as  a unit.  The  test  program  has  a different  set  of  con- 
straints than  the  earlier  development  phases.  However,  some  of  the  requirements 
are  common  with  the  earlier  requirements.  Key  characteristics  required  to  exercise 
and  test  the  operational  flight  program  follow. 

3. 1.3.1  Exercise  of  All  Modes 

The  requirements  are  similar  to  those  for  problem  identification  and  recreation. 
All  inputs  to  the  system  must  be  available  and  controllable  if  all  parts  of  the  program 
are  to  be  checked  to  insure  that  they  were  not  impacted  by  changes  in  other  areas. 
Before  a new  flight  program  version  is  released,  a thorough  check  of  each  section  of 
the  program  should  be  made  in  a systematic  manner.  For  effectivity  this  implies  not 
only  the  ability  to  exercise  all  modes,  but  also  the  next  requirements, 

3. 1.3.2  Scenario  Generation 

This  phase  of  tape  development  no  longer  requires  man  in  the  loop  testing.  A 
formal  test  procedure  is  required.  The  rigid  and  structured  nature  of  such  a proce- 
dure lends  itself  to  automated  checkout  control.  Automated  control  not  only  allows 
faster  setup  of  the  proper  test  conditions  and  therefore,  speeds  the  testing  program, 
but  insures  proper  test  conduct  by  limiting  operator  errors  and  allows  repeatability 
of  the  procedure.  A further  advantage  is  that  test  procedures  can  build  upon  previous 
procedures  to  the  point  where  a very  comprehensive  test  procedure  can  be  developed 
and  maintained  with  minimal  effort. 

3. 1.3.3  Real  Time  Analysis 

The  use  of  real  time  analysis  techniques  allows  a continuous  evaluation  of  each 
portion  of  the  program  under  test.  The  inclusion  of  performance  criteria  in  the  test 
program  also  insures  that  a thorough  analysis  of  requirements  has  been  made  and 
contributes  to  the  confidence  in  both  the  checkout  procedures,  and  the  final  results. 

A further  advantage  of  real  time  analysis  is  the  capability  for  greater  depth  of 
analysis.  Using  present  equipment  and  procedures,  the  amount  of  data  that  can  be 
gathered  by  an  operator  is  limited.  Performing  the  necessary  conversions  on  the 
data  before  analysis  further  slows  and  limits  the  manual  capabilities.  Tools  which 
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allow  faster,  more  accurate,  and  greater  data  gathering,  conversion  and  analysis 
greatly  enhance  the  ability  to  perfonn  maintenance  engineering. 

3. 1.3.4  Test  Documentation 

One  of  the  requirements  for  any  testing  program  is  adequate  documentation. 
Information  on  the  test  procedure,  evaluation  criteria,  a record  of  events,  results  of 
analysis,  etc.,  are  necessai’y.  Accurate  documentation  using  manual  methods  is  very 
difficult  and  time  consuming  to  obtain.  However,  it  can  easily  be  obtained  as  a fall- 
out Item  in  an  automated  system. 

3. 1.3.5  Error  Recording  and  Recovery 

If  by  chance  an  error  is  found,  it  is  necessary  to  have  information  on  how  the 
error  was  generated,  what  the  symptoms  are  and  areas  of  the  program  affected. 
Information  on  how  the  error  was  made  can  be  found  in  a trace  of  the  instructions  and 
data  prior  to  the  error  detection.  This  can  be  done  using  data  recording  techniques. 
Symptoms  and  areas  of  the  program  affected  can  be  found  by  selective  dumps  and 
analysis  of  the  flight  computer  memory.  Error  recovery  is  necessary  so  that  once 
all  information  about  a problem  is  known,  the  test  can  continue  and  other  possible 
errors  found.  Without  this  feature  each  error  would  have  to  be  corrected  in  sequence 
before  the  test  could  be  resumed.  If  errors  are  interrelated,  this  could  cause  long 
and  unnecessary  delays. 

3. 1.3.6  Complete  Computer  Control 

The  above  requirements  are  best  Implemented  by  eliminating  the  human  inter- 
face element  and  allowing  complete  computer  control  of  the  test  program.  Without  it, 
the  manhours  expended  increase  development  costs.  Simple  errors  cause  program 
delays  and  confidence  in  the  final  product  is  lessened. 

3. 1.3.  7 Tool  Provision 

There  are  two  possible  ways  to  provide  a set  of  tools  meeting  the  above 
requirements. 

3. 1.3.7. 1 Totally  Digital  Simulation.  Using  this  technique,  the  flight  computer, 
converter,  and  all  interface  units  are  simulated  on  a general  purpose  computer.  It 
has  the  advantage  that  access  to  data  within  the  'flight  computer"  is  very  easy  to 
obtain  and  the  analysis  of  problems  is  simplified.  More  analysis  can  be  made  as  the 
program  proceeds  because  the  operational  flight  program  is  not  executed  or  exercised 
in  real  time.  Hov/ever,  the  non-real  time  operation  has  definite  disadvantages  also. 
First,  real  time  to  execution  time  ratios  of  300:1  are  possible.  This  makes  the 
large  scale  general  purpose  computer  time  very  expensive.  Secondly,  the  slowness 
of  operation  means  that  a complete  evaluation  of  a program  can  cause  considerable 
delays  in  the  development  compared  to  the  same  checks  being  made  in  real  time. 
Further,  man  in  the  loop  control  is  extremely  difficult  to  implement  in  non-real  time. 
Another  problem  with  this  Implementation  is  that  the  simulation  of  the  flight  computer 
is  never  an  exact  model  of  the  real  thing.  Therefore,  confidence  in  the  results  is 
less  than  if  the  program  were  exercised  in  the  actual  flight  computer.  A further 
problem  is  the  size  of  computer  required.  Fully  digital  simulation  requires  large. 
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powerful  general  purpose  computers.  These  are  extremely  difficult  to  obtain,  control 
is  harder  to  achieve,  and  their  cost  for  initial  installation  and  maintenance  is  very 
high. 


3. 1.3.  7.2  Hybrid  Simulation.  This  technique  utilizes  the  actual  flight  computer 
and  converter  set  and  any  of  the  avionics  subsystems  that  operate  identically  on  the 
ground  or  in  the  air.  Those  portions  of  the  system  that  are  sensitive  to  their  environ- 
ment are  simulated.  The  airframe,  atmosphere  and  sensors  are  simulated  as  in  a 
fully  digital  simulation.  The  hybrid  configuration  has  the  advantages  of  operating  in 
real  time,  providing  confidence  that  the  computer  complex  will  not  behave  differently 
than  the  airborne  computer  complex.  Additional  advantages  include  the  ability  to  give 
man  in  the  loop  capabilities,  and  the  usefullness  of  smaller  and  more  inexpensive 
computers.  The  price  of  all  of  this  is  that  it  is  harder  to  obtain  visibility  of  the 
computer  programs  as  they  operate. 

3. 1.3.  8 Hybrid  Approach 

In  view  of  the  relative  advantages  and  disadvantages  between  pure  digital  and 
hybrid  simulation,  SMAMA  felt  tliat  the  most  useful  approach  to  satisfy  the  overall 
requirements  for  tape  development  was  the  hybrid  approach.  This  study  is  an  evalua- 
tion of  that  approach. 

3.2  POTENTIAL  APPROACHES  CONSIDERED 
3.2. 1 Groundrules 

Certain  groundrules  had  to  be  established  near  the  beginning  of  the  study  to 
assure  that  the  recommended  tape  verification  facility  would  satisfy  basic  require- 
ments and  also  to  somewhat  limit  the  number  of  approaches  considered.  These 
groundrules  were  determined  by  looking  at  the  general  problem  of  maintaining  and 
validating  the  F-111  operational  flight  programs-and  reviewing  existing  capabilities 
In  this  area  in  order  to  point  out  deficiencies  which  must  be  reduced  or,  if  possible, 
eliminated. 

Two  methods  currently  exist  that  could  be  used  for  verifying  operation  of  the 
flight  programs.  These  methods  w'ere  used  by  Autonetics  during  the  avionics  <ievelop- 
ment  program.  First,  the  program  for  each  computer  (General  Navigation  Computer 
{GNCJ,  Weapon  Delivery  Computer  (W'DCJ,  and  Navigation  Computer  Unit  [NCUJ)  is 
tested  in  a stand-alone  configuration.  This  method  is  called  tape  verification  tests 
(TVT).  Next,  the  three  programs  are  integrated  in  static  compatibility  demonstration 
test  using  the  ITE.  In  this  latter  test,  the  three  programs  are  integrated  only  during 
a 'Tree  inertial" navigation  run.  For  subsequent  demonstration  tests,  the  NCU  does 
not  participate.  The  ITE  was  primarily  designed  as  an  interface  test  aid,  but  can  also 
be  used  to  a limited  extent  for  flight  tape  checkout.  The  inadequacies  of  the  ITE  for 
this  purpose  arc  pointed  out  in  detail  in  Section  G.G.  Basically,  these  deficiencies 
are  limited  control  of  inputs,  insufficient  capability  for  data  monitoring  and  gathering, 
and  inability  to  create  actual  dynamic  flight  conditions.  Although  the  ITE  has  been 
shown  to  be  inadequate  for  overall  flight  program  verification,  it  is  the  only  capa- 
bility SMAMA  has.  Therefore,  it  is  recommended  that  the  test  station  be  left  intact 
to  be  used  as  an  interface  test  aid  and,  to  a limited  extent,  as  a backup  facility. 
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TVT  was  the  method  used  by  Autonetics  for  the  formal  functional  qualification  of 
the  F-111  program  tapes  during  the  initial  stages  of  tape  development.  It  consisted  of 
a collection  of  software  tests  which  verified  the  functions  contained  on  the  GNC  and 
WDC  program  flight  tapes  (separately)  using  only  the  IBM  -l-PI  computer  to  simulate 
necessary  flight  equipment  and  interface  signals.  The  only  flight  hardw  are  used  were 
the  two  4-PI  compulci’s  as  shown  in  Figure  3-1.  One  computer  contained  the  test  con- 
trol software  and  was  designated  the  primary  computer.  This  software  then  exercised 
the  functions  contained  on  the  flight  program  tape,  which  was  loaded  in  the  secondary 
computer.  This  fact  alone  points  out  one  of  the  major  TVT  deficiencies  in  that  only 
one  flight  program  could  be  verified  at  one  time  with  no  simultaneous  operation  of  the 
GNC  and  WDC  program  tapes.  Another  major  deficiency  was  that  the  only  actual  flight 
hardware  used  were  the  two  computers.  All  the  other  hardware  necessary  to  exercise 
the  flight  programs  were  simulated  with  software.  This  not  only  meant  that  there  was 
no  way  to  check  the  interface  and  synchronization  of  the  system,  but  also  it  resulted 
In  the  test  control  program  being  very  dependent  on  the  flight  program.  It  is  difficult 
to  use  software  to  simulate  all  the  detailed  characteristics  of  the  actual  hardware.  In 
many  cases,  changes  were  made  to  the  flight  program  which  were  still  compatible 
with  the  hardware,  but  turned  out  to  be  incompatible  with  the  software  simulation. 

This  required  that  modifications  be  made  to  the  test  control  program,  causing  long 
time  delays  In  verifying  a flight  program  after  a new  assembly  had  been  made. 

TVT  was  primarily  designed  for  final  program  tape  verification.  A predeter- 
mined flight  profile  was  "flown"  automatically.  Manual  control  was  awk~svard  which 
made  it  practically  useless  as  a troubleshooting  or  debugging  tool.  It  was  difficult  to 
make  repeated  tests  of  a specific  function  without  rerunning  the  entire  mission  profile 
because  there  was  no  convenient  way  of  reinitializing  the  flight  program  to  a particular 
set  of  conditions. 

TVT  was  run  open  loop.  There  were  no  data  resulting  from  flight  program 
computations  being  sent  back  through  the  system.  These  data  were  only  recorded  and 
compared  against  a set  of  predetermined  verification  values.  Recording  of  these  data 
required  modifications  to  the  flight  program  to  create  a data  pump.  These  modifica- 
tions consisted  of  a small  interface  subroutine  which  was  placed  in  unused  memory 
locations.  In  some  instances  there  was  not  sufficient  unused  memory  and  some  of  the 
flight  program  code  had  to  be  overlayed.  In  both  cases,  the  flight  program  being  exer- 
cised with  TVT  is  not  Identical  to  the  program  tape  actually  being  flown  in  the  aircraft. 

In  the  initial  stages  of  development  of  the  F-111  program  tapes,  some  effort  was 
put  into  building  an  F-111  hybrid  simulator.  Although  the  project  was  discontinued 
before  it  reached  its  full  potential,  it  was  operational  to  an  extent  which  allowed  some 
modes  to  be  exercised.  It  was  primarily  designed  to  check  navigation  steering  and 
weapon  delivery  mechanization.  There  were  two  phases  of  development.  In  the  first 
phase,  some  of  the  simulation  was  done  with  an  analog  computer,  particularly  the 
aerodynamic  model.  The  second  phase  was  completely  digital.  Due  to  the  lack  of 
reliability  and  accuracy  of  the  analog  equipment,  the  digital  simulation  was  found  to 
be  far  superior. 
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After  reviewing  the  past  and  present  simulation  capabilities,  and  pointing  out 
deficiencies  with  consideration  of  the  problem  at  hand,  the  following  groundrules  were 
established  as  guidelines  for  the  approach  to  be  taken. 

1.  Simulation  computers  to  be  digital. 

2.  Capability  to  exercise  the  flight  computers  as  a system  (l.e. , simultaneous 
operation  of  the  GNC,  VVDC,  and  NCU). 

3.  Capability  to  run  closed  loop. 

4.  No  contamination  of  the  flight  program. 

5.  Include  as  much  actual  avionics  hardware  as  possible,  considering  time, 
cost,  and  realism. 

3.2.2  Configuration  Options 

Once  the  basic  groundrules  had  been  established,  other  options  were  studied. 
Some  of  these  were  consideration  of  modifying  the  ITE  to  be  Included  as  part  of  the 
simulator,  automatic  control  versus  "man  in  the  loop"  operations,  and  decisions  as 
to  what  hardware  should  be  used  and  what  should  be  simulated. 

It  was  decided  to  use  the  existing  nosebay  mockups  to  house  the  avionics  hard- 
ware. Rationale  for  this  decision  is  presented  in  Section  5.4. 

It  was  also  determined  that  'Vnan  in  the  loop"  and  automatic  control  are  compli- 
mentary in  flight  program  maintenance  and  verification.  The  need  for  both  exists. 

One  of  the  basic  requirements  of  a simulator  is  the  ability  to  search  for  a problem. 

To  do  this  efficiently,  the  inputs  should  be  under  control  of  the  operator.  This  would 
be  advantageous  in  that  the  simulation  would  not  be  constrained  to  a pre-determlned 
mission  profile.  For  reproducing  and  solving  problems,  the  ability  to  run  specific 
modes  or  functions  individually  is  needed.  Once  a problem  area  has  been  isolated, 
repeated  tests  could  be  made  exercising  that  specific  portion  of  the  flight  program. 

The  man  in  the  loop  would  have  complete  control  of  the  simulated  flight  and  would  be 
free  to  select  any  mode  of  operation  and  variances  of  these  modes.  A "man  in  the 
loop"  simulation  could  also  be  used  in  support  of  final  tape  verification.  Used  in  this 
sense,  it  would  be  more  of  a mode  verification  in  that  it  would  verify  whether  a mode 
functioned  properly,  but  it  would  be  lacking  In  checking  the  accuracy  of  the  flight  tape 
mechanization.  There  would  be  a loss  of  accuracy  due  to  the  Inability  to  manually 
duplicate  Inputs  in  repeated  runs.  The  major  portion  of  final  tape  verification  requires 
that  precise  mputs  be  used  and  that  outputs  be  checked  against  precomputed  answers 
for  accuracy.  This  is  best  done  by  removing  the  man  from  the  loop  and  generating  a 
predetermined  (canned)  flight  profile  run  entirely  under  computer  control.  Final 
checkout  would  be  made  by  comparing  results  against  a standard  profile.  This  stand- 
ard profile  would  not  change  between  different  versions  of  the  flight  program  unless 
the  actual  functions  were  altered. 

The  distinct  phases  of  flight  program  maintenance,  problem  reproduction,  prob- 
lem solving,  debugging  and  final  verification  could  be  handled  efficiently  with  these 
two  capabilities. 


It  would  seem  that  the  optimum  way  to  huild  a simulator  would  be  with  all  of  the 
avionics  hardware  included  to  duplicate  the  operational  system.  However,  this  intro- 
duces the  problem  of  "how  to  stimulate  the  sensors."  It  would  then  be  necessary  to 
simulate  tlic  environment  for  which  each  of  the  sensors  operate.  The  cost  and  time 
to  develop  these  environments  would  be  tremendous  ;md  reliability,  maintenance/ 
calibration  and  resulting;  availabilitv  problems  would  increase.  The  net  result  in 
using  the  actual  sensors  is  that  the  task  of  simulating  these  sensors  is  transformed 
Into  a more  difficult  task  of  simulating  their  environment.  Since  the  primary  purpose 
of  the  simulator  is  to  maintain  the  flight  programs,  software  simulation  of  the  sensors 
would  give  them  more  flexibility  and  possibly  more  realism.  Additional  hardware 
versus  simulated  hardware  rationale  as  well  as  detailed  equipment  listing  are  pre- 
sented in  Section  5. 

3.2.3  Phase  Development 

To  get  maximum  use  out  of  a simulator  as  soon  as  possible,  it  is  necessary  to 
plan  a multiphased  development.  A detailed  plan  is  given  in  Section  5.5.  In  general. 
Phase  1 will  support  operation  of  all  the  modes  and  functions  of  the  flight  program  tape 
with  the  exception  of  the  following. 

1.  Astrocompass  Model  (FB-111  only) 

2.  Alr-to-Air  Radar  modes  (F-lllD  only) 

3.  Takeoff  and  landing  modes 

4.  Error/Noise  Injection  into  models 

The  above  could  be  added  during  Phase  2 or  when  desired/required. 

Phase  3 will  Inelude: 

1.  SRAM  Missile  model 

2.  HUD  stability  and  accuracy  tests 

In  order  to  keep  a smooth  transition  between  different  phases,  it  is  recommended 
that  the  simulation  routines  be  modular.  The  addition  of  new  models  would  have  no 
effect  on  existing  models.  The  only  modifications  necessary  would  be  to  the  executive 
subprogram  to  include  scheduling  of  additional  models.  This  type  of  structure  would 
also  be  beneficial  for  maintenance  and  control  over  the  total  software  simulation 
package. 
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4.  HISTORY  OF  PROJEQ 


4.1  GENERAL 

The  F-111  avionics  profjram  has  completed  the  production  cycle  and  the 
equipment  is  becoming  operational.  The  Air  P'orce  Engineering  responsibility  for 
the  F-111  flight  programs  is  presently  being  transferred  to  SMAMA.  As  a result  of 
its  role  as  prime  contractor  for  the  MARK  II  Avionics,  Autonetics  is  presently  under 
contract  to  SMAMA  for  perform  F-111  MARK  II  Engineering  Services.  This  contract 
was  amended  in  July  1973,  to  include  an  engineering  study  to  establish  the  feasibility 
of  a digitally  controlled  simulation  facility  that  would  be  used  by  SMAMA  for  F-111  | 

flight  program  maintenance  and/or  development. 

The  SMAMA  responsibility  covers  programs  for  the  FB-lllA,  F-lllF  and 
F-lllD.  Implicit  within  the  responsibility  is  the  requirement  to  provide  program 
revisions  to  the  operating  commands  at  least  once  each  year.  SMAMA  has  defined 
procedures  for  preparation  and  configuration  control  of  the  programs.  There  are 
several  possible  alternate  approaches  toward  tape  verification  and  checkout  that  are 
discussed  in  other  sections  of  this  report. 

It  should  be  noted  here  that  tape  program  support  has  become  extremely 
Important  in  modern  avionics  due  to  increasing  use  of  computer  controlled  weapon 
delivery  systems.  Lack  of  provisions  for  dyrjamic  ground  testing  results  in  expen- 
sive and  time  consuming  flight  test  verifications  that  will  never  catch  all  of  the 
errors  in  the  computer  program.  This  is  due  in  part  to  inadequacy  of  in-flight  instru- 
mentation and  inability  to  identify,  intentionally  enter  and  exactly  reproduce  conditions 
In  which  subtle  problems  can  occur.  The  result  of  incomplete  software  validation  is 
decreased  operational  capability  and  flight-crew  confidence  along  with  apparent 
maintenance  problems  within  the  operational  commands. 

The  study  was  started  with  a thorough  review  of  the  F-111  hybrid  simulation 
previously  performed  by  Autonetics.  It  was  concluded  from  this  review  that  substan- 
tial documentation  is  available  to  support  a fully  digital  simulation  program  and  that  ■ 

such  a program  is  feasible. 

The  F-111  '^jroblem  book"  was  reviewed  and  the  problems  documented  as  of 
1 July  1973  were  organized  by  categories  that  indicated  a need  for  dynamic  verification 
of  problem  solution  for  approximately  25  percent  of  the  existing,  identified  problems. 

Additionally,  solutions  of  a majority  of  all  of  the  identified  problems  will  require  tape 
revision  (>80  percent  for  FB-lllA). 

A baseline  simulation  concept  was  defined  that  was  ultimately  refined  to  the 
hardware/software  configuration  described  in  this  report.  This  refinement  was  per- 
formed with  guidance  from  two  primary  areas;  on-site  participation  by  Mr.  Larry 
Thompson  of  SMAMA,  who  provided  insight  into  SMAMA's  task  and  goals;  and;  visit 
and  consultation  with  personnel  at  Naval  Weapons  Center,  China  Lake,  California, 
who  have  a similar  tape  responsibility  for  the  A-7  flight  programs. 
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5.  SUPPORTING  DOCUMENTATION 


5.1  GENERAL 

This  section  contains  the  detailed  results  of  the  study.  These  results  consist  of 
the  following  information: 

1.  Definition  of  the  hardware  baseline  recommendations.  This  baseline,  with 
associated  software,  is  sufficient  to  allow  the  dynamic  software  test  and 
evaluation  and  can  be  expanded  in  hardware/software  mix  and  complexity  as 
desired  to  extend  or  modify  the  approach. 

2.  Conceptual  definition  of  the  software.  The  recommended  software  partition- 
ing is  defined  with  emphasis  in  detail  placed  on  the  Real  World  Simulation 
^stem  (RWSS)  and  the  Subsystem  Simulation  System  (SSS). 

Autonetics  feels  that  these  two  software  systems  should  receive  primary 
early  development  emphasis  within  bounds,  limitations  or  groundrules  of 
the  other  systems. 

3.  A discussion  of  alternate  discrete  sensor  approaches  and  variations  in 
Intended  use  of  the  simulator. 

4.  Discussion  of  the  trade-offs  considered  during  the  conceptual  design  and  the 
reasons  for  the  choices  selected. 

5.  Description  of  the  recommended  program  (and  magnitude  costs)  for  attaining 
the  recommended  simulation  capability. 

6.  Rationale  for  extending  the  existing  capability  to  include  dynamic  simulation. 

5.2  BASELINE  APPROACH 

The  F-111  baseline  simulation  system  was  derived  by  examining  four  major 
factors.  These  were  (1)  the  requirement  to  rapidly  reproduce  and  correct  operational 
flight  program  (OFP)  problems  (2)  to  maintain  the  integrity  of  the  OFP  during  test  and 
evaluation,  (3)  to  test,  verify  and  evaluate  all  OFP’s  collectively  in  a dynamic  environ- 
ment short  of  flight  testing,  and  (4)  comparison  of  the  aforementioned  factors  with 
existing  and/or  post-simulation  facilities.  The  factor  which  contributed  most  to  the 
baseline  design  approach  was  maintaining  the  integrity  of  the  OFP's.  This  meant  that 
no  contamination  of  any  OFP  would  be  allowed  during  test  and  verification.  Hence, 
debugging  aids  such  as  data  pumps,  external  synchronization,  etc. , were  not  to  be 
used.  The  no  risk  approach  to  achieve  this  goal  is  described  below. 

5. 2. 1 Hardware  for  the  Baseline  Simulation  System 

Figure  5-1  is  a block  diagram  of  the  F-111  baseline  simulation  system.  The 
system  can  be  characterized  as  being  digital,  modular,  and  under  complete  manual  or 
computer  control  at  the  operator's  option.  It  is  envisioned  that  two  identical  system 
configurations  will  exist;  one  for  the  F-lllD  and  one  for  the  FB-lllA/F-lllF.  The 
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Figure  5-1.  F-111  Baseline  Simulation  System 


only  hardware  that  is  unique  for  each  system  configuration  is  the  simulator  and  switch- 
ing unit.  However,  even  within  this  unit  there  are  functional  modules  which  are  iden- 
tical for  all  F-111  systems.  The  paragraphs  below  describe  each  major  hardware 
item  shown  in  Figure  5-1.  In  addition,  the  primary  role  within  the  simulation  system 
is  noted. 

5.2. 1.1  Bus  Interfaces 

AH  hardware,  connected  to  either  simulation  processor,  is  interfaced  via  an 
asynchronous  high  speed  bus.  All  data  transfer  is  initiated  by  the  processor.  The 
maximum  throughput  of  either  bus  is  one  million  (16-bit)  words-per-second. 

In  addition,  a link  exists  between  the  processors.  This  link  provides  for  the 
transfer  of  a single  word  or  block  of  words  over  a direct  memory  access  (DMA) 
channel.  The  maximum  throughput  is  250,000  (16-bit)  words-per-second. 

The  above  two  interfaces  are  based  on  the  PDP-11  family  of  computers.  In 
particular,  they  correspond  to  the  UNIBUS  data  path  and  DMA  UNIBUS  link  respectively. 

5. 2. 1.2  Switches  ' 

The  bus  switches  shown  are  used  to  time-share  a device  between  two  processors. 
Each  switch  is  both  software  and  manually  controllable.  The  switch  is  based  on  the 
PDP-11  UNIBUS  switch. 

5. 2. 1. 3 Master  Simulation  Processor 

The  role  of  this  processor  is  to  act  as  the  system  supervisor  (or  test  controller). 
The  majority  of  the  man/machine  interactions  will  be  handled  by  this  processor.  Such 
functions  as  interface  switching,  test  setups,  test  operator  commands  and/or  requests, 
and  control  of  the  other  processor  are  handled  herein.  The  processor  selected  is  the 
PDP-11/45  with  floating  point  capability. 

5. 2. 1.4  Support  Simulation  Processor 

The  primary  role  of  this  processor  is  to  execute  the  subsystem  and  air  vehicle 
digital  models.  The  data  interchange  required  with  the  F-111  system  under  test  is 
with  the  simulator  and  switching  unit.  When  dynamic  (time  varying  inputs)  simulation 
Is  desired,  control  can  be  either  from  the  master  simulation  processor  or  overriden 
Iqf  the  control  stick  and  throttle  interface  as  shown  in  Figure  5-1.  The  processor 
selected  is  the  PDP-11/45  with  floating  point  capability. 

5. 2. 1.5  Main  Memory  No.  1 

This  memory,  associated  with  the  master  simulation  processor,  will  contain 
48K  (16-bit)  words.  The  cycle  time  is  900  nanoseconds.  The  memory  selected  is  the 
PDP-ll/45  magnetic  core  memory. 

5. 2. 1.6  Main  Memory  No.  2 

This  memory  is  associated  with  the  support  simulation  processor.  It  will 
contain  32K  (16-bit)  words  with  a cycle  time  of  450  nanoseconds  (MOS  Memory)  and 
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16K  (16-bit)  words  of  core  memory.  This  higher  speed  memory  (from  the  core)  is 
required  because  of  the  large  number  of  matrix,  transcendental  and  trigonometric 
manipulations  associated  with  the  models.  Further,  many  calculations  involve  double 
precision  floating  point  which  require  four  memory  accesses.  Because  of  the  expected 
high  duty  cycle  usage  (based  on  Autonetics  hybrid  simulator  effort  and  data  from  the 
A-7  simulator  system  at  the  Naval  Weapons  Center,  China  Lake),  the  faster  memory 
Is  justified. 


5. 2. 1.  7 Main  Memory  No.  3 

This  memory  is  Identical  to  Main  Memory  No.  1 except  is  contains  only  16K 
(16-blt)  words.  Its  primary  usage  will  be  to  enable  interprocessor  data  transfers 
over  the  DMA  UNIBUS  link.  It  will  also  store  those  software  modules  not  directly 
associated  with  model  execution. 

5. 2. 1.8  Typewriter 

This  peripheral  will  be  time-shared  between  the  two  simulation  processors.  Its 
primary  role  Is  to  provide  individual  off-line  computer  control  during  system  build-up 
and  Initial  turn-on  sequences.  The  device  select^  is  the  DEC  writer  data  terminal. 

5.2. 1.9  Operator  Control  Keyboard/Monitor 

This  device  is  the  primary  test  operator  Interface  with  the  F-111  system  under 
test.  Using  software  stored  in  the  master  simulation  processor,  the  operator  can 
command  and/or  make  requests  to  control  the  simulation  system.  Operator  actions 
Include  F-111  system  mode  control,  data  entry,  display  requests,  key-in  patch 
corrections  to  the  OFF  and  model/mission  profile  setups.  All  keyboard  entries  will 
be  recorded  either  on  the  line  printer  or  the  typewriter.  When  this  device  is  opera- 
tive, no  other  keyboard  device  can  be  used  to  initiate  system  control  actions.  The 
specific  unit  selected  is  the  DEC  alphanumeric  video  display  terminal.  The  CRT  can 
display  up  to  1440  characters  simultaneously.  Other  features  include  direct  character 
addressability  and  display  of  video  from  a TV  camera  simultaneously  with  computer- 
generated alpha-numeric  data. 

5.2.1.10  Test  Support  Monitor  No.  1 

This  unit  will  be  primarily  used  to  control  the  simulation  of  serial  channels  to 
the  F-111  converter  set.  Up  to  three  channels  can  be  setup  via  this  device.  The 
monitor  is  a CRT  which  will  display  the  data  being  transmitted  over  the  serial  channel. 
Also  included  would  be  the  control  bits  status  and  data  addresses.  The  display  of  all 
data  variables  will  be  In  either  engineering  units  or  binary  as  requested  by  the  opera- 
tor. The  unit  selected  is  identical  to  the  operator  control  keyboard/monitor  described 
previously.  This  monitor  will  be  used  as  backup  for  the  primary  operator  control 
keyboard/monitor  should  the  latter  fall. 

5.2.1.11  Test  Support  Monitor  No.  2 

The  primary  role  of  this  device  is  to  monitor  the  parallel  transfers  among  the 
elements  of  the  Digital  Computer  Complex  (DCC).  These  data  transfers  occur  at  four 
points  as  shown  and  discussed  in  para  5.2.1.14.  Monitoring  at  points  1 and  2 pro- 
vides the  capability  to  display  all  external  data  entering  and  leaving  computer  memory. 
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It  also  provides  the  means  to  monitor  I/O  throughput.  Points  3 and  4 will  permit 
monitoring  the  intercomputer  data  transfers.  The  same  display Aeyboard  options 
exist  as  discussed  for  Test  Support  Monitor  No.  1.  This  unit  is  also  a DEC  alpha- 
numeric video  display  terminal. 

5.2.1.12  Line  Printer 

This  peripheral  will  provide  for  large  printouts  of  data,  memory  dumps,  traces, 
etc.  It  can  also  be  used  to  record  all  operator  interactive  conversation  with  the  PDP- 
11/45  computers.  The  device  selected  is  a medium  speed  (300  LPM),  132  column, 

96  character  printer  or  equivalent. 

5.2.1.13  Disk  Drive 

This  mass  memory  device  will  store  all  test  modules  to  be  executed  in  the 
simulation  processors.  In  addition,  data  associated  with  static  and  dynamic  testing  of 
F-111  systems  is  stored.  The  switch  permits  either  simulation  processor  to  access 
the  desk  individually.  Further,  the  OFP's  for  the  GNC  and  WDC  will  be  stored  in  this 
device.  Initial  loads  of  the  DCC  will  be  controlled Trom  the  operator  control  keyboard/ 
monitor  after  the  simulation  processors  have  been  brought  on-line.  The  device 
selected  is  a DEC  moving  he^  disk  system.  The  capacity  provided  is  1.2  million 
(16-bit)  words  on  a removable  disk  pack.  It  is  primarily  via  the  removable  disk  pack 
that  an  FB-lllA  test  setup  can  be  converted  to  an  F-lllF  setup. 

The  hardware  descriptions  thus  far  have  been  related  to  the  PDP-11  family  and 
associated  peripherals.  This  hardware  represents  an  investment  which  can  be  used 
for  any  system,  not  just  F-111.  While  the  complement  of  equipments  is  tailored  to 
fit  the  early  needs  for  an  F-111  simulation  system  facility,  the  growth  to  accommo- 
date a larger  complex  is  inherent  in  the  PDP-11  design.  This  growth,  unique  to  the 
F-111  systems,  is  discussed  later  in  this  section. 

The  equipment  to  be  described  now  relates  specifically  to  the  F-111.  They  are 
the  "black  boxes"  necessary  to  provide  the  interfaces  between  the  test  control  hard- 
ware (PDP-11  family)  and  the  F-111  system  under  test. 

5.2.1.14  I/O  Data  Monitor  Unit 

'The  primary  role  of  this  imit  is  to  monitor  selected  data  sets  being  transferred 
within  the  DCC.  The  interfaces  to  be  monitored  are  shown  in  Figure  5-2.  Interfaces  1 
and  2 are  externally  controlled  inputs  (ECI),  i.e. , the  converter  set  must  initiate  all 
information  transfers  to/from  the  computers  (the  computers  are  IBM  4PI  CP-2  digital 
computers).  Information  transferred  can  be  data  or  I/O  Instructions,  the  latter  going 
from  the  computer  to  the  CS  only.  Computer  memory  accessible  to  the  CS  (and  hence 
the  data  monitor)  lie  between  addresses  2048  and  4095.  To  the  CS,  these  addresses 
correspond  to  0 to  2047,  respectively.  Based  on  the  current  F-111  memory  map 
design,  the  I/O  instructions  (which  are  accessed  by  the  CS  for  execution)  are  stored  in 
the  lower  end  of  the  2048  word  block.  The  external  I/O  data  are  stored  in  the  upper 
portion. 
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Figure  5-2.  I/O  Data  Monitor  Interfaces  With  DCC 


The  I/O  data  monitor  unit  will  be  designed  to  provide  the  following  capabilities: 

1.  Monitor  all  words  to/from  any  serial  channel  in  a block 

2.  Monitor  any  aingle  word  to/from  any  serial  channel 

3.  Monitor  any  group  of  consecutively  addressed  nonserial  words 

4.  Monitor  any  single  or  paired  nonserial  words  (such  as  radar  altitude  or 
slne/coslne  pitch,  respectively). 

5.  Monitor  all  I/O  Instructions  for  a particular  rate  group 

6.  Measure  the  I/O  throughput  for  each  rate  group 

To  accommodate  the  worst  case  rate  group,  a 512  (17-blt)  word  buffer  would  be  pro- 
vided In  the  data  monitor  unit. 

Besides  the  monitor  capability  of  Interfaces  1 and  2 (Figure  5-2),*  growth  will  be 
provided  to  load  parameters  directly  into  the  2049  computer  memory  block  or  extract 
data.  That  Is,  this  unit  will  be  able  to  simulate  the  CS  interface  and  initiate  data 
transfers  with  computer  memory.  This  capability  will  enable  the  test  operator  to  per- 
form a tape  verification  test  of  the  F-111  OFP  resident  in  both  IBM  4P1  computers. 
This  collective  testing  of  flight  programs  would  add  another  measure  of  confidence  to 
the  acceptability  of  the  software. 
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Interfaces  3 and  4 (Figure  5-2)  will  be  monitored  to  enable  the  <est  operators  to 
verify  proper  intercomputer  data  transfers.  These  parallel  channels  are  Program 
Controlled  Outputs  (PCO),  i.  e. , all  transfers  are  initiated  by  the  sending  computer. 

The  importance  of  monitoring  this  channel  is  related  to  the  functional  redundancy  and 
partitioning  concept.  For  example,  during  a full  operational  configuration  (a  fullup 
DCC),  the  target  acquisition  parameters  used  by  the  weapon  delivery  computer,  origi- 
nate in  the  GNC.  They  must  be  transferred  from  the  GNC  to  the  WDC.  Such  problems 
as  transport  lag  and  intercomputer  synchronization  would  be  easier  to  identify  and 
resolve  with  this  monitoring  capability.  The  growth  to  simulate  the  PCO  operation  will 
also  be  accommodated  for  interfaces  3 and  4.  This  will  enable  the  test  operator  to 
insert  variables  directly  into  computer  memory.  However,  this  would  be  primarily  a 
debugging  aid  rather  than  an  operational  test  and  verification  tool. 

The  specific  operation  of  this  unit  will  be  under  control  of  the  test  operator. 

Test  Support  Monitor  No.  2 will  be  the  primary  interactive  device.  All  data  for  dis- 
play will  be  routed  through  the  master  simulation  processor  in  order  to  generate  the 
proper  format.  The  I/O  data  unit  will  be  designed  in  a modular  fashion  to  ensure 
growth  capability  for  data  injection  as  well  as  ease  of  maintenance. 

5.2.1.15  Computer  Monitor  and  Control  Unit 

Just  as  the  I/O  data  monitor  imit  "listens"  to  transfers  external  to  the  computer 
(IBM  4PI),  this  unit  enables  the  test  operators  to  "listen"  to  information  transfers 
Internal  to  the  computers.  Its  primary  purpose  is  to  assist  in  testing,  checkout, 
optimization  and  measuring  duty  cycle  and  instruction  mixes  in  real-time.  The  unit 
will  provide  an  interface  with  each  IBM  4PI  computer  memory  bus  through  the  AGE 
connectors.  This  interface  enables  the  test  facility  to  monitor  all  memoi'y  transfers 
between  the  CPU  and  I/O.  This  capability  would  obviate  the  necessity  to  provide  a 
software  data  pump  in  either  or  both  OFP's. 

This  device  has  already  been  designed  and  built  for  a version  of  another  IBM 
4PI  computer,  specifically  the  one  used  in  the  A-7  aircraft.  However,  the  memory 
bus  structures  are  identical.  The  unit  Is  being  used  currently  at  the  Naval  Weapons 
Center,  China  Lake.  Some  of  the  typical  functions  of  this  unit  include  (for  each  4 PI 
computer): 

1.  Display  of  the  contents  of  any  word  in  memory.  The  displayed  information 
would  be  updated  each  time  the  selected  address  contents  was  read  from  or 
loaded  into  the  memory  cell. 

2.  Provide  a breakpoint  register.  Whenever  the  memory  location  specified  in 
the  breakpoint  register  is  accessed,  an  Interrupt  would  cause  computer 
operation  to  halt.  This  action  would  also  be  used  to  control  simulation/test 
activity.  This  feature  would  also  stop  real-time  clock  counter  operation  so 
that  a restart  could  occur  without  major  reinitializations. 

3.  Provide  upper  and  lower  limit  registers.  Whenever  the  memory  location 
being  accessed  is  between  the  register  limits,  a signal  can  be  generated. 
Under  operator  control,  the  signal  would  cause  a halt  (similar  to  breakpoint), 
identify  when  a multiple  loop  has  been  entered,  or  find  the  execution  time  of 
a loop. 
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4.  Perform  a continuous  trace  function.  The  unit  would  store  the  last  "n"  data 
and  Instruction  addresses.  An  indicator  to  differentiate  between  the  two 
would  bo  provided.  Whenever  a computer  stoppage  occurs,  the  trace  would 
provide  the  information  to  debug  the  cause  of  the  error  trap,  malfunctioning 
loop  or  unexpected  halt. 

5.  Allow  single  step  instruction  execution  once  the  computer  had  been  halted. 
(Either  automatically  via  breakpoint,  etc. , or  manually. ) 

6.  Provide  for  miscellaneous  aids  such  4s  determining  (1)  execution  time  of 
any  routine  or  segment  thereof,  and  (2)  instruction  mixes,  etc. 

One  of  the  most  important  uses  of  this  Interface  unit  will  be  to  load  the  OFP's 
Initially  into  the  4P1  computers.  In  addition,  the  capability  to  load  key-in  patches  and 
dump  memory  onto  the  line  printer  is  also  facilitated  by  the  unit.  Further  design 
details  of  this  unit  can  be  foimd  in  Ref  8. 

5.2.1.16  Simulator  and  Switching  Unit 

■ To  test  an  F-lll  system,  there  are  two  items  in  the  baseline  simulation  that 
must  be  unique.  One  is  the  disk  pack.  The  other  is  the  simulator  and  switching  unit. 
This  unit  provides  the  direct  interface  with  the  applicable  F-lll  converter  set  for  all 
simulated  signals  computed  in  the  support  simulation  processor  (see  Figure  5-3).  In 
addition,  manually  entered  data  for  any  serial  channel  transfer  to  the  converter  set 
will  also  be  routed  through  this  unit. 

The  functions  of  this  unit  can  be  characterized  by  examining  its  interfaces. 

There  are  four  primary  interfaces;  DCC,  nosebay  mockup,  control  stick/throttle,  and 
support  simulation  processor.  The  DCC  Interface  will  provide  electrical  compatibility 
for  all  signals  generated  by  any  portion  of  the  simulation  system.  These  include  dis- 
crete Inputs  to  both  IBM  4PI  computers,  and  discrete,  serial  and  analog  inputs  to  the 
converter  set.  The  mechanization  of  this  Interface  must  be  such  that  whenever  a 
simulated  signal  is  to  be  routed  to  the  DCC,  the  actual  signal  originating  within  the 
nosebay  mockup  must  be  switched  out.  This  switching  function  if  not  accomplished  by 
physically  unplugging  the  connector,  will  be  handled  in  this  unit.  It  is  noted  that  not 
all  signals  simulated  by  the  simulation  system  will  enter  the  DCC  directly.  Some, 
such  as  air  vehicle  pitch  and  roll,  will  be  routed  to  the  J-Box  in  the  mockup.  These 
simulated  signals  would  replace  those  normally  coming  from  the  attitude  sensors 
(such  as  the  inertial  reference  unit  and  auxiliary  flight  reference  system).  The  spe- 
cific subsystems  whose  signal  interfaces  must  te  accommodated  by  this  unit  are 
identified  in  Figure  5.  3. 

The  second  Interface  of  this  unit  is  with  the  F-lll  nosebay  mockup  exclusive  of 
the  DCC.  Any  simulated  signal  must  also  have  its  actual  counterpart  routed  Into  this 
unit  for  appropriate  switching.  An  example  would  be  the  dv)ppler  radar.  Since  it 
would  be  desirable  to  permit  this  radar  to  interface  in  its  normal  manner  with  the 
DCC,  as  well  as  be  simulated,  its  interface  must  be  routed  through  this  simulator  and 
switching  unit.  The  test  operator  would,  as  part  of  the  test  setup,  make  the  appropri- 
ate hookup  (i.e. , actual  or  simulated).  Also,  as  mentioned  above,  certain  simulated 
signals  will  be  routed  directly  to  the  nosebay.  For  example,  the  Central  Air  Data 
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Figure  5-3.  SAS  Unit  Functional  Interfaces  Approach 


Computer  (CADC)  will  be  simulated.  This  unit  would  provide  outputs  identical  to  those 
of  the  actual  CADC.  Hence,  they  can  be  routed  directly  to  the  applicable  hardware  in 
the  nosebay  mockup. 

The  Navigation  Computer  Unit  (NCU)  is  a digital  computer,  not  a part  of  the 
DCC.  It  is  dedicated  to  operate  with  the  inertial  reference  unit  (IKU)  and  normally 
receives  a clock  interrupt  signal  from  the  IHU.  Since  the  IRU  will  be  simulated,  this 
clock  signal  must  be  provided  for  In  the  design  of  the  sijnulator  and  switching  unit. 

The  clock  provides  the  system  timing  lor  llie  inertial  computations  being  executed  in 
the  NCU.  The  clock  signal  must  provide  for  a 6-l/sec  clock  interrupt  to  the  NCU 
located  in  the  nosebay.  As  a possible  means  to  minimize  the  number  of  different  clock 
sources  used  by  the  various  lest  and  operational  computers,  it  is  recommended  that 
this  64/sec  clock  signal  also  drive  both  simulation  processors. 

The  third  function  of  the  simulation  and  switching  unit  is  to  accept  Inputs  from  a 
simulated  control  stick  and  throttle.  Provision  is  being  made,  via  this  interface,  to 
permit  the  test  operator  to  "fly"  the  digital  air  vehicle  models  manually  in  addition  to 
implementing  canned  mission  profiles.  Hence,  anytime  these  hand  grips  are  activated, 
the  air  vehicle  models  will  use  them  as  an  override.  Reverting  back  to  canned  mis- 
sion profiles  will  require  positive  test  operator  action  via  the  control  keyboard/monitor 
device. 

The  final  interface  is  with  the  support  simulation  processor  via  the  UNIBUS  data 
channel.  All  signals  destined  for  the  F-lll  system  under  test  will  be  transferred 
over  this  bus.  It  is  important  to  note  that  some  simulated  interface  modules  will  be 
common  among  the  F-lll  systems.  For  example,  the  IRU  interface  with  the  NCU  Is 
Identical  for  all  F-lll  systems.  Similarly,  the  CADC  interface  is  very  nearly  the 
same.  Since  both  of  these  would  be  simulated  in  any  test  configuration  for  any  system, 
their  hardware  Interface  modules  should  be  designed  to  be  compatible  with  any  simu- 
lator and  switching  unit.  In  order  to  provide  commonality,  time-sharing  of  hardware 
circuits  is  not  recommended  for  these  modules.  Also,  by  having  identical  hardware 
interface  modules  among  the  systems,  the  software  control/test  modules  can  also  be 
used  In  various  systems. 

5.2.2  Software  for  the  F-lll  Baseline  Simulation  System 

The  software  to  be  developed  and/or  acquired  for  execution  within  the  Baseline 
Simulation  System  has  been  segmented  into  six  categories.  These  are: 

1.  Executive  Operating  System  (EOS) 

2.  Man/Machine  Interactive  System  (MMIS) 

3.  Subsystem  Simulation  System  (SSS) 

4.  Real  World  Simulation  System  (RWSS) 

5.  Peripheral  Device  Handlers  (PDH) 

6.  Data  Base  Management  System  (DBMS) 
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The  partitioning  of  these  software  packages  into  the  three  primary  simulation  system 
hardware  items  is  shown  in  Figure  5-4.  Each  software  package  is  described  below. 

5. 2. 2.1  Executive  Operating  System  (EOS) 

This  software  will  be  a modified  version  of  DEC  real  time  system  executive 
(RSX-llD).  The  primary  functions  are: 

1.  PDF  turn-on  initialization 

2.  Multl-PDP  handshal^ing 

3.  Scheduling  of  test/simulation  modules 

4.  PDP  simulation  system  test 

5.  Real  Time  Control  and  monitoring 

6.  System  I/O  control 

It  is  envisioned  that  the  majority  of  test/simulation  software  modules  will  be  resident 
in  main  memory.  These  modules  are  loaded  initially  from  disk  storage.  The  emphasis 


Figure  5-4.  Software  Partitioning  for  the  Baseline  Simulation  System 


Is  to  minimize  roll  iii/roll  out  of  modules.  This  uses  processor  duty  cycle  which  is  at 
a premium.  However,  due  to  resident  memory  capacity,  certain  modules,  such  as 
periodic  status  report  generators,  background -t>pe  modules,  and  other  nonreal  time 
tasks,  will  of  necessity  be  stored  on  the  disk.  It  is  the  responsibility  of  the  EOS  soft- 
ware to  control  this  interchange  in  order  to  have  optimum  duty  cycle  utilization  for 
test  module  execution. 

5. 2. 2. 1. 1 PDP  Turn-on  Initialization.  This  function  will  react  to  primary 
power  application.  Its  primai’y  purpose  is  to  orderly  transition  the  processors  to  a 
predictable  state  in  order  to  initiate  additional  EOS  functions.  As  a minimum,  a gross 
hardware  self  test  will  be  conducted.  Passage  of  this  gross  test  will  ensure  the  oper- 
ator that  the  turn-on  sequence  is  proceeding  normally. 

5.  2. 2.1.2  Multi-PDP  Handshaking.  This  function  determines  the  availability  of 
other  PDP  processors  which  must  be  coordinated  and  brought  on  line. ' The  baseline 
jqjproach  will  be  to  designate  one  PDP  as  the  Master  Simulation  Processor  with  the 
other  PDP  providing  support.  The  specific  support  would  be  established  by  the  Master 
as  directed  by  test  operator.  The  multl-PDP  status  will  be  provided  to  the  operator. 
There  will  be  no  automatic  reconfiguration  performed  in  the  event  of  primary  PDP 
system  hardware  failures.  Some  form  of  multi-PDP  clock  synchronization  may  be 
required  in  order  to  obtain  repeatable  and  coordinated  test  results. 

5. 2.  2. 1.3  Scheduling  of  Test/Simulation  Modules.  The  scheduling  algorithm 
will  be  simple  in  order  to  minimize  executive  overhead.  Hence,  it  is  recoinxnended 
that  all  modules  be  permanently  scheduled  within  their  particular  rate  group.  Further, 
to  allow  for  multiple  contractors  to  generate  specific  test  modules,  a standardized 
interface  would  be  established  between  the  schedules  and  the  modules  themselves.  This 
approach  also  provides  a flexible  structure  for  future  changes,  additions,  and/or 
deletions. 

It  Is  envisioned  that  all  real-time  test  modules  will  be  resident  in  main  memory 
at  all  times.  Additional  test  modules  would  be  brought  in  from  bulk  storage  as  dic- 
tated by  the  test  operator  and/or  EOS.  A major  concern  is  the  duty  cycle  to  be  used 
for  each  of  the  test  modules.  Hence,  as  part  of  the  standardized  interface,  provision 
will  be  made  to  measure  the  duty  cycle  of  each  test  module  whenever  executed. 

5. 2. 2. 1.4  PDP  Simulation  System  Test.  This  function  will  continuously  monitor 
the  performance  of  the  test  system  (hardware  and  software).  Discrepancies  will  be 
reported  to  the  test  operator.  The  sole  purpose  of  this  function  is  to  assure  the  opera- 
tor that  the  test  setup  Is  operating  properly.  This  will  enable  him  to  concentrate  his 
efforts  on  the  system/problem  being  evaluated.  If,  for  some  reason,  either  test  pro- 
cessor or  the  disk  file  fall,  the  simulation  system  will  be  shutdown  and  require 
operator  action. 


5. 2. 2. 1.5  Real  Time  Control  and  Monitoring.  This  function  is  the  main 
"driver"  of  the  EOS.  The  test  modules  will  be  scheduled  in  various  rate  groups.  The 
specific  rate  group  will  be  derived  from  the  clock  interrupts.  These  will  be  controlled 
either  by  the  internal  PDP  clock  mechanization  under  software  management,  or  from 
an  external  source.  The  external  source  could  be  a centralized  test  system  clock.  A 
viable  candidate  would  be  the  same  clock  which  drives  the  NCU.  Since  the  Inertial 


platform  will  be  simulated,  a clock,  which  normally  is  furnished  to  the  NCU  by  tlie 
platform,  must  be  mechanized.  This  clock  will  be  provided  in  the  Simulation  and 
Switching  Unit. 

5.2.2. 1.6  System  I/O  Control.  All  I/O  Including  that  among  the  test  processors, 
test  interactive  devices,  bulk  storage,  F-111  interface  units,  etc.  will  be  handled  by 
this  function.  The  control  will  be  partitioned  such  that  I/O  signals  related  to  the  F-111 
system  under  test  will  be  separated  from  test  hardware-oriented  signals.  The  pro- 
grams for  I/O  operation  will  reside  in  each  applicable  PDF  processor.  Activation  of 
any  one  segment  of  the  I/O  program  will  be  initiated  by  the  real  time  control  and 
monitoring  function. 

5. 2.2. 2 Man/machine  Interactive  System  (MMIS) 

This  software  interprets  the  test  operator's  commands/requests  and  takes  the 
appropriate  action(s).  For  the  baseline  simulation  system,  the  primary  functions 
included  herein  are: 

1.  Data/Command  entry  and  disposition 

2.  Data/Status  formatting  and  display 

3.  Test  setup  and  configuration  control 

4.  OFP  Verification  and  Validation 

This  software  package  will  provide  the  operators  with  the  tools  to  communicate 
with  the  F-111  system  under  test  in  order  to  control  its  operation.  With  this  inter- 
action, the  operators  can  configure  the  test  setup  to  reproduce  a flight  program 
problem,  insert  corrections  to  enable  him  to  assess  the  problem  solution,  and  verify 
flight  program  operation  either  in  a segmented  or  full  operational  environment.  The 
operation  of  the  Computer  Monitor  and  Control  Unit,  and  the  I/O  Data  Monitor  Unit 
are  controlled  by  the  software  comprising  this  package.  Any  comparisons  between 
pre-calculated  results  and  actual  values  will  be  handled  by  the  software  modules  of 
this  package. 

5. 2. 2.2.1  Data/Command  Entry  and  Disposition.  During  the  testing  of  an  F-1 11 
system,  all  manually-entered  data  and/or  commands  destined  for  the  system  under 
test  will  be  first  interpreted  by  this  function.  Procedure/format  errors  will  be 
assessed.  Once  the  inputs  have  been  processed,  dissemination  of  the  results  will  take 
place.  Hard  copy  recording  will  take  place  if  appropriate.  In  most  cases,  the  results 
will  be  sent  to  the  applicable  data  blocks.  From  here,  other  test  modules  and/or  the 
I/O  control  function  will  use/distribute  the  data.  The  specific  interactive  devices  with 
which  this  function  will  interface  are  the  operator  control  keyboard/monitor  and  both 
test  support  monitors. 

5. 2.  2.  2. 2 Data/Status  Formatting  and  Display.  The  purpose  of  this  function 
will  be  to  primarily  present  to  the  test  operator,  data  and/or  status  of  the  current  test 
in  progress.  This  information  will  be  formatted  according  to  the  desires  of  the  oper- 
ator and  stored  in  the  data  base  for  display  and/or  hard  copy  recording. 
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5. 2.  2.  2.  3 Test  Setup  and  CoTifii^ration  Control.  It  would  be  desirable  for  the 
operator  to  confipjre  the  test  setup  from  the  h.leractive  devices.  This  would  include 
establishing  hardware  linkages  and  software  module  iuikages.  Further,  the  setup 
should  be  stored  and/or  recorded  for  future  use  and/or  retest  setup. 

In  addition,  all  operator  actions,  especially  those  affecting  the  F-111  system 
under  test  (e. g. , insertion  of  patch  key-ins,  initialization  data  for  a specific  test,  etc.) 
would  be  recorded.  The  sequence  of  these  actions  can  then  be  used  to  retrace  the 
operator's  steps  should  it  be  necessary  to  repeat  tests  or  debug  a problem.  This 
function  would  maintain  a log  of  the  test  setups.  Some  of  these  setups  would  be  pre- 
canned and  established  for  specific  kinds  of  tests  and/or  validations.  Others  would  be 
determined  by  the  operator  during  the  course  of  a particular  activity.  He  has  the 
option  of  saving  this  setup  for  future  callup.  The  software  associated  with  this  function 
would  maintain  these  test  setup  configurations.  Upon  operator  request,  a "menu"  of 
the  various  test  setup  options  would  be  presented  on  the  CRT.  The  operator  could  then 
select  the  setup  desired  and  the  test  system  would  establish  this  configuration  auto- 
matically. If  manual  operations  are  necessary  (such  as  entering  data  or  connecting 
different  equipments),  these  would  be  displayed  to  the  operator. 

• 5. 2. 2.2.4  OFF  Verification  and  Validation.  Because  of  the  importance  of  the 
SITS  capabilities  related  with  this  function,  Para  5.  2.4  is  entirely  allocated  for  its 
description. 

5. 2. 2. 3 Subsystem  Simulation  System  (SSS) 

This  software  package  consists  of  modules  which,  when  executed,  simulate  the 
functional  operation  of  the  applicable  F-111  subsystems.  Both  MKII  and  non  MKII 
subsystems  will  be  simulated.  There  are  two  types  of  subsystem  simulation  modules. 
These  are: 

1.  Static  subsystem  Interface  simulation 

2.  Functional  subsystem  simulation 

Since  the  current  F-111  ITE  provides  a good  deal  of  static  Interface  capability, 
the  main  emphasis  will  be  to  develop  the  functional  subsystem  models.  These  models 
wbuld  be  executed  in  the  Support  Simulation  Processor  as  shown  in  Figure  5-4. 
However,  based  on  the  subsystems  to  bo  simulated  in  the  baseline  system,  certain 
static  interface  capability  will  result  as  a natural  fallout. 
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5. 2.  2. 3. 1 Static  Subsystem  Interface  Simulation.  The  primary  purpose  of  this 
software  is  to  simulate  the  actual  "serial"  interface  from  a subsystem  to  the  Converter 
Set  (CS).  For  example,  if  the  Doppler  radar  normally  transmits  three  serial  words  in 
a cyclic  pattern,  there  would  be  a simulation  of  this  interface.  The  capability  to 
change  the  words  individually  and/or  collectively  by  the  operator  will  be  accommodated. 
In  addition,  the  ability  to  setup  the  nondata  bits  (i.e.,  control,  validity,  and  parity) 
will  also  be  provided. 


In  addition  to  simulating  serial  Interfaces,  the  ability  to  simulate  analog  inter- 
faces will  be  required.  For  example,  it  is  envisioned  that  the  Analog  Air  Data 
Computer  would  be  modeled  in  the  test  processors.  Hence,  it  Is  feasible  to  setup  the 
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output  of  the  model  to  some  static  configuration  for  the  purpose  of  testing  the  F-111 
system.  This  would  duplicate  the  capability  of  the  current  ITE,  that  requires  a num- 
ber of  "pots"  to  be  setup  to  achieve  the  same  effect. 

The  software  modules  would  cither  store  pre-canned  values  for  output  or  accept 
manual  changes  from  the  operator.  These  modules  would  be  overriden  whenever  a 
functional  subsystem  simulation  was  activated  by  the  operator. 

5. 2. 2. 3.2  Functional  Subsystem  Simulation.  This  package  of  software  modules 
will  be  initially  stored  in  disk  storage.  According  to  the  test  setup,  the  applicable 
modules  will  be  brought  into  resident  memory.  They  will  be  executed  at  the  rate 
required  to  simulate  subsystem  functional  performance.  Each  subsystem  will  be 
examined  separately  to  determine  the  best  means  for  simulation.  The  major  distinc- 
tion is  that  the  models  represent  subsystem  functional  performance  as  opposed  to 
hardware  design.  As  the  dynamic  model  computes  the  variables  for  output,  the  capa- 
bility to  control  certain  nondata  bits  (especially  parity  and  validity)  from  the  inter- 
active devices  would  be  desirable.  Noise  transients  and/or  hardware  faults  could  then 
be  introduced  by  the  operator  and/or  at  pre-canned  events.  The  subsystem  models 
will  be  capable  of  either  open  loop  or  closed  loop  operatjon  as  required  by  the  test 
setup. 


The  functional  requirements  of  the  individual  models  are  defined  from  the 
interface  level.  In  all  cases,  the  models  perform  two  tasks.  First,  they  transform 
the  reference  data  into  the  coordinate  system  that  is  consistent  with  the  actual  sensors. 
Second,  as  an  operator  option,  inputs  such  as  bias  and  scalefactor  errors,  plus  ran- 
dom noise,  can  be  added  to  the  input  flow.  The  signal  interface  of  each  model  is 
shown  in  Figures  5-5  through  5-13.  The  signal  type  (i.e. , analog,  serial  digital,  and 
discrete)  are  noted  along  with  the  differences  between  the  FB-111,  F-111  F and  F-lllD. 
The  figures  show  the  signals  going  directly  to  the  converter  set,  NCU  or  the  J-BOX. 
This  is  simplified  to  show  the  destination  within  the  central  computer  complex. 

Actually,  the  data  will  be  collected  in  local  data  bases  and  sent  to  a main  buffer  in  the 
Simulation  and  Switching  Unit  (SAS).  From  there  it  is  sent  to  the  corresponding  model 
buffers.  Up  to  this  point  all  the  information  is  digital.  From  these  buffers,  it  is 
converted  to  the  required  signal  type  and  sent  to  the  avionics  hardware.  Similarly, 
the  data  flow  from  the  converter  set  to  the  models  is  not  a direct  path.  The  loop  is 
closed  through  the  SAS  and  real  world  simulation  system.  During  open  loop  operation, 
these  data  would  be  monitored  to  verify  OFF  computations  but  would  not  be  fed  back 
through  the  system.  MK  II  converter  set  areas  I,  II,  and  III  are  also  noted  in  the 
figures.  Area  I corresponds  to  the  analog  input  and  serial  input/output  for  the  GNC. 
Area  III  is  the  same  for  the  WDC  and  Area  II  corresponds  to  analog  output  from  the 
DCC. 


5. 2. 2.4  Real  World  Simulation  System  (RWSS) 

The  purpose  of  this  software  is  to  generate  output  signals  for  the  SSS  and  MMIS 
software  as  shown  in  Figure  5-14.  From  these  signals,  the  SSS  will  simulate  the 
required  MK  II  and  non-MK  II  subsystems  identified  elsewhere  in  this  report.  Also 
the  MMIS  will  utilize  these  signals  as  reference  data  to  monitor  and  verify  the  F-111 
Avionics  performance.  Hence,  the  RWSS  generated  output  signals  will  represent  the 
real  (or  true)  dynamic  state  and  environment  of  the  F-111  aircraft. 
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Figure  5-5.  ARS  Model  Signal  Interface 


Figure  5-6.  DRS  Model  Signal  Interface 


The  generation  of  the  RWSS  output  signals  will  be  accomplished  with  the  four 
software  models: 

1.  F-111  Automatic  Flight  Control  System  (AFCS)  Model, 

2.  F-111  Aircraft  Dynamics  Model, 

3.  Earth  Model,  and 

4.  Atmosphere  Model. 

Figure  5-14  shows  a general  block  diagram  of  the  four  RWSS  software  models 
interfacing  with  (1)  the  SSS  software,  (2)  the  MMIS  software,  (3)  the  hardware  tie-in 
with  the  F-111  Nosebay  Mockup,  and  (4)  the  man  shown  within  the  F-111  Nosebay 
Mockup  for  man-in-the-loop  simulations  and  tests. 

The  total  and  detailed  functional  capabilities  of  the  baseline  RWSS  from  the 
standpoint  of  the  interface  shown  in  Figure  5-14  and  others,  which  are  omitted  for 
brevity,  will  be  defined.  This  definition  will  be  performed  to  the  extent  that  no  major 
changes  will  be  necessary  to  the  baseline  RWSS  during  the  development  of  the  ultimate 
RWSS. 
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Figure  5-8.  Flux  Valve  Model  Signal  Interface 
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Figure  5-9.  AFRS  Model  Signal  Interface 
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Figure  5-10.  RAS  Model  Signal  Interface 
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Figure  5-11,  ACCXTR  Model  Signal  Interface 
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Figure  5-14.  Block  Diagram  of  the  Heal  World  Simulation  System  Software 


The  following  paragraphs  describe  tl>e  HWSS  as  envisioned  to  be  implemented  in 
terms  of  its  significant  functional  capabilities,  basic  input  and  output  signals,  the  the 
recommended  HWSS  software  models.  Unl'ess  otherwise  stated,  the  descriptions  con- 
tained in  the  following  paragraphs  apply  to  both  the  baseline  and  ultimate  HWSS. 

5.  2.2. 4.1  Significant  Functional  Capabilities.  The  HWSS  software  will  provide 
the  means  to  simulate  the  complete  AFCS  and  the  six  degrees-of-freedom  aircraft 
dynamics  of  the  I'-lll  aircraft.  The  HWSS  output  signals  will  provide  true  informa- 
tion related  to  the  dynamic  state  and  environment  of  the  F-11 1 aircraft  relative  to  the 
Earth.  Tbe  accuracy  level  of  this  information  will  Ixj  least  for  the  baseline  and  will 
increase  to  the  maximum  possible  upon  development  of  the  ultimate  HWSS  software. 

The  baseline  RWSS  will  be  structured  and  implemented  such  that  it  will  facilitate 
the  selection  of  various  complexities  of  the  F-III  AFCS  and  Aircraft  Djmamics  models. 
This  selection  will  be  requested  by  the  test  operator  via  the  MMIS  software  at  the 
beginning  of  each  simulation  or  test.  Simple  models  are  suggested  to  be  implemented 
for  the  baseline  HWSS  for  two  reasons,  i.e. , (1)  they  will  be  the  most  often  used 
models  and  will  be  adequate  for  most  use,  and  (2)  they  require  the  least  effort  and  time 
to  Implement,  with  negligible  risk,  and  will  be  required  for  most  of  the  early  simula- 
tion use. 

Both  reasons  are  quite  valid  since  general  simulations  and  tests  will  be  per- 
formed much  sooner  and  more  often  than  detailed  ones.  From  the  experiences  at 
Autonetics  and  at  the  Naval  Weapon  Center,  this  is  the  case  because  simple  models 
are  easier  to  set  up  via  the  MMIS,  require  less  computer  time  and  the  resulting  data 
are  easier  to  interpret.  Also,  the  i-esulting  data  will  be  adequately  accurate  for  most 
simulations  and  tests  envisioned. 

The  following  paragraphs  delineate  the  functional  capabilities  of  each  of  the  four 
RWSS  systems. 


5.  2. 2.4. 1.1  F-111  Automat’o  Flight  Control  System  (AFCS)  and  Aircraft 
Dynamics  Models.  The  F-111  AJCS  augments  the  flight  stabilitj'  of  the  F-111  aircraft 
throughout  its  flight  regime.  It  d rects  the  aircraft  according  to  the  auton\atic  steering 
and  manual  commands  by  me.'ins  of  appropriate  control  surface  deflections.  The  steer- 
ing commands  are  provided  by  the  MK  II  and  non-MK  II  avionics  equipment  for  various 
steering  modes.  The  appropriate  control  surface  deflections  are  derived  by  the  AFCS 
for  optimum  pilot  comfort  such  as  coordinated  turns  for  lateral  maneuvers. 

The  baseline  F-111  Aircraft  Dynamics  Model  will  consist  of  a point  mass  six 
degrees-of-freedom  (6DOF)  model.  That  is,  details  related  with  the  aei-odynamic 
lift,  drag,  and  side  forces  and  the  external  aerodynamic  roll,  pitch,  and  yaw  moments 
will  not  be  simulated.  The  purpose  of  this  model  will  be  primarily  to  simulate  the 
trajectory  of  a point  mass  with  the  body  rates  controlled  proportionallj'  by  either  the 
automatic  steering  or  manual  commands  from  the  mockup.  The  baseline  F-111  AFCS 
Model  will  simulate  coordinated  turns  whenever  lateral  maneuvers  are  required. 

The  subsequent  models  of  the  F-111  AFCS  and  Aircraft  Dynamics  leading  to  the 
ultimate  RWSS  software  are  recommended  to  be  as  follows: 

The  ultimate  RWSS  software  will  contain  two  AFCS  models,  i.e. , (1)  the  base- 
line model  and  (2)  the  full-blown  mcxlel  partially  documented  in  Ref  1 in  terms  of 
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Laplace  transform  block  diagrams.  This  documentation  covers  the  F-lllA  aircraft 
instead  of  the  specific  aircraft  of  interest  (FB-ill,  F-lllD,  and  F-IJIF),  however 
those,  too,  should  be  available  to  SMAr\L\.  The  ultimate  ItWSS  software  will  contain 
four  aircraft  dynamics  models,  i.o. , (1 } the  baseline  point  mass  CDOF,  (2)  the  canned 
trajectory  similar  to  that  implemented  in  the  Aidonetics  F-111  Tape  V'^erification  Tests 
(TVT),  (3)  the  6 DOF  with  linearized  aerodynamics  coefficients  about  specified  nominal 
flight  conditions,  and  (1)  the  full-blown  GDOF  with  aerodynamic  coefficient  function 
generations  covering  the  entire  flight  regime  of  the  aircraft  of  interest. 

The  purpose  of  the  baseline  point  mass  6DOF  aircraft  dynamics  model  is  for 
simplicity  in  frequently  used  test  cases  in  which  extreme  accuracy  of  dynamic  simula- 
tion is  not  required  as  explained  previously. 

The  purpose  of  the  canned  trajectory  model  version  is  to  generate  exact  aircraft 
trajectory  profiles  which  will  be  repeatable  bit-by-bit  from  one  identical  run  to 
another.  Such  repeatable  exact  trajectory  profiles  will  be  useful  for  detail  NCU,  GNC, 
and  WDC  software  checkout. 

The  purpose  of  the  linearized  6DOF  model  is  to  study  weapon  delivery  or  other 
flight  sensitive  problems  such  as  ILS  and  A1L.\  steering  modes  about  a nominal  condi- 
tion. This  model  will  be  useful  to  check  out  the  basic  6DOF  aircraft  dynamics  model 
against  the  solution  of  hand-performed  analyses  which  are  basically  linear  in  order  to 
be  soluble. 

The  purpose  of  the  full-blown  6DOF  model  is  to  study  the  entire  F-111  weapon 
.system  in  order  to  investigate  detailed  problems  which  may  be  encountered  throughout 
a wide  flight  regime  of  the  aircraft.  Simulations  of  long  mission  time  with  large 
dynamics  range  concerned  with  minute  details  of  the  aircraft  dynamics,  such  as  stall 
conditions,  will  require  such  model.  Kef  4 documents  the  full  blown  GDOf'  equations 
of  motion  of  a generalized  aircraft.  These  equations,  with  minor  modifications, 
together  with  data  associated  with  the  F-111  aerodynamics  coefficients  and  engine 
characteristics  represent  the  full-blown  6DOF  Aircraft  Dynamics  Model. 

Since  the  ultimate  SITS  will  be  utilized  for  simulations  and  tests  to  the  finest 
detail,  it  is  recommended  that  data  related  with  the  AFCS  and  aei'odynamics  for  the 
specific  aircraft  (FB-111,  F-lllD,  and  F-lllF)  be  obtained  and  used  in  the  ultimate 
RWSS  software. 


5.2. 2. 4. 1.2  Earth  and  Atmosphere  Models.  The  Earth  and  Atmosphere  models 
will  be  as  documented  in  Ref  3 with  some  modifications  related  with  the  navigation 
mechanization  coordinate  system.  In  the  F-111  project,  the  wander  angle  navigation 
mechanization  coordinate  system  is  used  and  implemented  for  world  wide  navigation 
purposes.  Ref  3 uses  the  north  oriented  navigation  mechanization  coordinate  system 
and  is  written  with  singularities  at  the  Earth  poles. 

The  Earth  Model  will  be  an  oblate  spheroid  which  rotates  about  its  polar  axis. 
The  constants  of  this  model  will  be  as  documented  in  Ref  7 in  order  to  be  consistent 
with  the  NCU,  GNC,  and  WDC  OFP's. 

The  Atmosphere  Model  will  be  as  documented  in  Ref  3.  The  China  Lake  area 
wind  profiles  will  be  used  until  wind  profiles  of  a different  area  of  interest  are  identi- 
fied and  available. 
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5.  2.2. 4.2  Input/ Output  Interface.  This  section  lists  the  primary  input  and 
output  signals  of  tTicTlWbb  software,  Hedinition  of  the  total  and  detailed  interface  will 
be  required  during  the  development  of  the  baseline  lUVSS.  This  definition  will  be  such 
that  no  major  changes  will  be  necessary  to  the  baseline  HWSS  during  the  development 
of  the  ultimate  ItUdS. 

It  is  to  be  noted  that  this  section  lists  the  primary  signals  from  the  functional 
point-of-view.  The  detailed  characteristics  of  the  signals  such  as  type  of  signal, 
update  signal,  etc. , are  not  pertinent  for  the  overall  context  of  this  repoi't.  However, 
the  detailed  interfaces  used  in  the  Autonetics  F-III  Hybrid  Simulation  efforts  are 
documented  in  Ref  1 and  6.  Therefore,  these  references  can  be  utilized  as  guidelines 
during  the  development  of  the  baseline  RWSS. 

Also,  signals  related  with  the  software  functions  performed  by  the  EOS  and  PDH 
are  intentionally  omitted  since  the  SrrS  simulation  and  test  functions  are  of  prime 
interest  at  this  time  rather  than  the  simulation  control  software  operation. 

5.  2. 2.4.2. 1 Input  Signals.  The  primary  input  signals  are  from  the  MMIS  and 
SSS  software  and  the  mockup  hardware  tie-in  as  shown  in  Figure  5-14. 

These  signals  together  with  comments  are  listed  below: 

1.  MMIS  Software  Inputs 

Simulation  Configuration  Options 

a.  AFCS  Model  Options 

(1)  Simple  model  to  simulate  coordinated  turns,  to  be  developed  for 
baseline  RWSS. 

(2)  Full-blown  model  simulating  adaptive  gains,  nonlinearltles, 
redundancies,  etc. 

(3)  F-111  aircraft  option  to  select  the  appropriate  AFCS  character- 
istics unique  to  the  FB -111,  F-lllD,  or  F-lllF  aircraft. 

b.  Aircraft  Dynamics  Options 

(1)  Point  mass  6DOF  to  simulate  navigation  and  other  functions  which 
are  insensitive  to  detail  aerodynamic  characteristics,  to  be  devel- 
oped for  the  baseline  RWSS. 

(2)  Canned  6DOF  maneuvers  for  exact  aircraft  trajectories  such  as 
exactly  +45  deg  (rather  than  +45.01  deg)  initial  heading  for  a Great 
Circle  Course.  This  option  will  be  useful  for  detail  bit-by-blt  OFP 
checkout  against  scientific  computer  solutions  which  are  easily 
generated  under  such  exact  trajectory  conditions. 
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(3)  Liiioarized  GDOF  with  aerodynamics  coefficients  linearized  about 
a nominal  point  condition.  This  option  will  be  useful  to  investigate 
detail  aircraft  characteristics  such  as  stability  during  ILS/AILA 
Navigation  Steering  mode  about  a nominal  condition  of  interest  onlj'. 


(4)  Nominal  point  condition  for  tlie  preceding  option  (Mach  number, 
altitude,  wing  sweep,  etc.). 

(5)  Full  blown  GDOF  to  simulate  the  entire  flight  regime  of  the 
specific  F-111  aircraft. 

(6)  F-111  aircraft  option  to  select  the  appropriate  aerodynamics 
coefficients  unique  to  the  FB-111,  F-lllD,  or  F-lllF  aircraft. 

Initial  Conditions 


a.  True  aircraft  position  and  velocity 

b.  True  aircraft  heading,  pitch,  and  roll  Euler  angles  and  body  angular 
rates. 

2.  SSS  Software  Inputs 
Initial  Conditions 

a.  True  platform  wander  angle. 

AFCS  Non-MK  II  Avionics  Feedback  Signals 

a.  Normal  and  Lateral  Accelerometer  inputs. 

b.  Yaw,  Pitch,  and  Roll  Rate  Gyro  Inputs.  i 

c.  CADC  Inputs. 

I 

d.  AFRS  Magnetic  Heading.  j 

3.  F-111  Nosebay  Mockup  Hardware  Inputs 

AFCS  Related  Signals  ^ j 

a.  AFCS  Auto/Manual  Override  Command.  i 

b.  Attitude  Good  Discrete. 

c.  J-BOX  Pitch  and  Roll  Attitudes.  j 

5. 2. 2. 4.2. 2 Output  Signals.  The  output  signals  are  those  generated  for  the  SSS  ^ 

and  MMIS  software.  U is  to  be  noted  that  all  of  those  output  signals  represent  the  real  j 
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or  true  dynamic  slate  and  environment  of  the  K-111  aircraft.  The  following  lists  are 
not  by  no  means  complete,  however,  the  primary  ones  and  those  with  which  the  base- 
line HWSS  will  be  concerned  are  listed; 


1.  F-ni  Aircraft  Dynamics  Model  (Xitputs 

a.  True  normal  and  lateral  acceleration. 

b.  True  yaw,  pitch,  and  roll  body  angular  rates. 

c.  True  angle  of  attack  and  side  slip  angles. 

d.  True  yaw,  pitch,  and  roll  Euler  angles. 

e.  True  airspeed. 

2.  Earth  Model  Outputs 

a.  True  Latitude,  Longitude,  and  Wander  Angle, 

b.  True  platform  components  of  velocity. 

c.  True  groundspeed,  groundtrack,  and  drift  angle. 

d.  True  heading  relative  to  true  north. 

e.  True  altitude  and  radii. 

f.  True  gravity  and  Coriolis  acceleration  components. 

g.  True  windspeed  and  wind  direction. 

h.  True  magnetic  heading. 

I.  True  magnetic  variation. 

J.  True  temperature,  pressure,  air  density,  and  speed  of  sound. 

5. 2. 2. 5 Peripheral  Device  Handlers 

This  package  consists  of  the  standard  PDP-family  of  peripheral  handlers. 
Included  are  (1)  diskdrive,  (2)  typewriter,  (3)  line  printer,  (4)  keyboards,  and  (5)  CHT 
monitors.  It  may  be  advantageous  to  merge  some  of  these  handlers  with  the  modules 
of  the  MMIS. 


5. 2. 2.6  Data  Base  Management  System 

The  F-111  baseline  simulation  system  data  base  comprises  the  global  data  blocks 
(on  the  disk  dile),  and  the  local  data  blocks  (in  each  simulation  processor).  The  local 
data  blocks  will  be  partitioned  such  that  Individual  modules  have  their  own  dedicated 
areas.  All  data  which  must  be  routed  among  the  modules  and  external  to  the 


processors  will  be  serviced  by  common  and  I/O  data  blocks  respectively.  This 
partitioning  will  aid  In  maintaining  the  desired  software  modularity  objective. 

5.2.3  Growth  Capability  of  the  Baseline  Simulation  System 

The  baseline  s\'stem  proposed  offers  many  ways  to  incorporate  growth.  For 
example,  the  UNIBUS  mecnanization  allows  many  more  peripherals  to  be  connected  to 
the  processor  as  future  requirements  dictate  a need.  Such  items  as  magnetic  tape 
recorders,  additional  CRT  monitors,  more  mass  memory,  etc.  can  be  added  directly. 
Further,  the  PBP-ll/45  can  be  interconnected  with  other  PDP's  to  form  different 
architectures  Including  multiprocessors  and  multicomputers  with  shared  memory. 

The  UNIBUS  concept  also  permits  each  interface,  at  the  Simulator  and  Switching  Unit, 
to  have  a unique  control  address.  This  flexibility  provides  an  additional  modularity 
level  for  growth.  The  only  restriction  on  the  number  of  devices  connected  to  the 
UNIBUS  is  throughput.  The  maximum  transfer  rate,  based  on  the  memory  selected, 
is  in  excess  of  1 million  (16-bit)  words-per-second. 

From  a software  viewpoint,  there  are  three  factors  which  contribute  most  to 
growth.  These  are  (1)  function  partitioning  to  promote  modularity,  (2)  standard 
executive  interface  with  test  modules  .and  (3)  use  of  a common  programming  language 
(such  as  FORTRAN).  Furthermore,  the  DEC  executive  real-time  system  has  the 
option  to  interleave  batch  jobs  if  desired.  One  possible  use  would  be  to  assemble 
corrections  to  the  F-111  OFP  while  testing  was  proceeding.  Updates  could  then  be 
made  directly  to  the  OFP  modules  stored  on  the  disk  file. 

It  is  desirable,  from  a cost  viewpoint,  to  purchase  the  PDP-11/45  peripherals 
anticipated  for  later  phases  during  the  Initial  order.  Hence,  three  additional  periph- 
erals are  defined  for  inclusion.  Peripheral  handlers  will  also  be  furnished.  However, 
application  software  to  interface  with  these  handlers  will  not  be  generated  until  Phase  2. 

1.  Two  800  bpl,  9 track  magnetic  tape  units  (Includes  controller) 

2.  One  300  1pm  card  reader 

3.  One  paper  tape  reader/punch 

5.2.4  OFP  Verification  and  Validation  (V  and  V) 

The  baseline  SITS  hardware  as  described  in  Para  5.  2. 1 with  adequate  memory 
and  appropriate  software  will  allow  the  performance  of  the  OFP  verification  and  vali- 
dation (V  and  V)  function  autonomously  and  with  a high  degree  of  automation.  That  is, 
once  the  ultimate  SITS  software  is  developed,  it  is  envisioned  that  such  function  will  be 
performed  without  the  aid  of  scientific  computers  and  with  a minimum  of  manual  oper- 
ations. Thus,  the  degree  of  completeness  and  efficiency  in  performing  this  function 
with  the  srrs  will  be  much  greater  than  those  which  can  be  achieved  with  the  ITE  and 
TVT  combined. 

The  related  software  that  will  allow  the  OFP  V and  V capabilities  as  envisioned 
to  be  Implemented  in  the  ultimate  MMIS  software  is  described  in  the  following  para- 
graphs. Those  portions  of  the  baseline  MMIS  are  identified  in  the  description. 
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The  primary  objectives  of  the  OFi’  V and  V function  are:  (1)  to  verify  the  OFP 
coding  (and  other  "debugging"  goals)  relative  to  the  program  requirements  and,  (2)  to 
validate  the  OFP  related  avionics  system  performance  relative  to  the  avionics  system 
specification  or  other  "performance  requirement"  documents.  These  objectives  or 
primary  capabilities  will  be  implemented  through  optimal  combinations  of  on-line  and 
off-line  processing  within  the  available  SFl'S  memory  and  processing  duty  cycle. 
Primary  source  of  data  for  satisfaction  of  objective  (1)  above  is  the  CMAC  with  the 
lODM  unit  as  the  primary  data  source  for  objective  (2). 

The  primary  task  of  the  on-line  processing  will  be  to  retrieve  designated  data 
for  the  off-line  processing.  The  retrieved  data  will  require  some  processing,  pri- 
marily to  reduce  the  amount  of  data  to  be  stored  in  the  Disk  File.  The  major  portion 
of  the  software  which  performs  the  OFP  V and  V function  will  be  for  the  off-line 
processing  of  the  retrieved  data. 

Some  of  the  major  tasks  which  the  off-line  processing  will  perform  related  to 
the  OFP  coding  verification  and  performance  validations  are: 

5.  2.4.1  Air-to-Ground  Weapon  Delivery  Evaluation. 

As  part  of  the  OFP  performance  validation,  this  task  will  be  performed  based 
upon  the  retrieved  instantaneous  true  condition  (from  the  HWSS)  at  weapon  release. 

^ means  of  much  more  complex  ballistic  computations  than  those  implemented  in  the 
OFP,  the  CEP  of  the  weapon  delivery  to  the  designated  target  will  be  determined. 
These  computations  will  also  include  separation  effects  and  wind  profiles  to  a degree 
of  accuracy  higher  than  that  implemented  in  the  OFP. 

5. 2. 4.2  Generation  of  Reference  Solutions  for  the  OFP  Coding  Verification 

The  extent  of  this  task  will  of  course  be  dependent  upon  the  extent  of  the  OFP 
coding  verification  desired.  That  is  the  total  OFP  coding  verification  will  require 
generation  of  the  total  reference  solutions.  These  reference  solutions  can  only  be 
generated  by  implementing  the  total  OFP  program  requirements  within  the  SITS 
processors  in  FORTRAN  IV  language. 

Such  extent  of  OFP  coding  verification  will  be  useful  during  the  OFP  optimization 
efforts  which  is  apparantly  evident.  Since  bit-by-bit  comparison  between  the  retrieved 
data  and  the  corresponding  reference  solutions  are  of  interest  to  detect  coding  errors, 
static  test  problems  similar  to  those  generated  during  the  FB-111  and  F-lllD  OFP 
developments  at  Autonetics  will  be  required.  Such  test  problems  will  be  required  for 
the  generations  of  variable  parameters  as  well  as  discrete  information  such  as  the 
state  of  a "flag".  Initially,  the  application  of  the  OFP  coding  verification  capability  of 
the  SrrS  can  be  oriented  at  verifying  only  those  OFP  codings  associated  with  the 
Implementation  of  flight  tape  problem  solutions  into  the  OFP. 

5.  2. 4.  3 Automatic  Test  Sequencing  for  the  OFP  Coding  Verification. 

This  task  will  be  intimately  associated  Para  5.  2. 4.  2.  The  purpose  of  this  task 
is  to  automate  the  entire  sequence  of  the  OFP  coding  verification  once  initiated  by  the 
test  operator.  The  pre-determlned  sequence  will  consist  of:  (1 ) SITS  and  DCC  set-up 
for  a static  test  problem,  (2)  initiation  of  the  on-line  processing  for  the  data  retrieval 
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of  the  static  test  results,  (3)  initiation  of  the  off-line  processing  to  perform  the  task  of 
Para  5.  2.  4.  2,  and  (3)  coding  error  evaluation  based  upon  a prestored  criterion  for  the 
specified  test. 

5.  2. 4.4  Memory  Tracing  of  Executed  Instructions. 

This  task,  in  conjunction  with  the  corresponding  on-line  processing,  will  process 
the  retrieved  data  and  will  map  the  entire  memory  of  the  DCC  under  test,  i.e. , the 
GNC  or  \VDC.  This  memory  map  will  be  formatted  and  output  on  the  Line  Printer  in 
a matrix  of  appropriate  dimension  (e*g.,  2^  by  2^).  Each  element  of  that  matrix  will 
correspond  to  a specific  memory  location  of  the  DCC  computer  under  test.  An  element 
with  a zero  will  indicate  a memory  location  which  was  not  accessed  by  the  CPU  of  the 
DCC  computer  under  test. 

Therefore,  for  a specific  test  mode,  the  resulting  memory  map  will  show  all  of 
the  instructions  executed  at  least  once  during  that  test  as  well  as  the  handled  variables. 
The  handled  variables  can  be  eliminated  from  this  matrLx  with  appropriate  decisions 
based  upon  the  instruction/variable  OFP  architecture  knowledge  that  can  be  stored  in 
the  software  associated  with  this  task. 

The  usage  of  the  resulting  memory  map  matrix  will  be  in  detecting  unexecuted 
instructions  for  all  possible  system  modes  which  are  possible  to  be  configured  bj’ 

Inputs  to  the  DCC  computer  under  test.  The  existance  of  unexecuted  instructions  will, 
(n  general,  indicate  invalid  program  requirements  or  mls-coding. 

5. 2.4.5  Data  Reduction  for  OFP  Performance  Validation. 

This  task  will  process  and  reduce  the  retrieved  data  in  appropriate  and 
predetermined  formats  for  the  purpose  of  OFP  performance  validation.  For  example, 
related  to  navigation  performance  validation,  this  task  will  determine  the  time  RMS 
errors  of  radial  velocity,  attitude,  and  heading;  the  maximum  CEP  rate;  and  the  CEP 
rate  as  a result  of  a least  square  Ht  to  a straight  line  of  the  time  history  of  CEP. 

The  software  development  to  accomplish  all  of  the  above  five  major  task  will  not 
be  considered  for  the  baseline  MMIS  because  of  the  time  and  effort  required  for  the 
development  of  such  software.  However,  the  baseline  MMIS  will  contain  the  on-line 
and  off-line  processing  software  to  perform  the  navigation-related  OFP  performance 
validation  as  described  briefly  in  Para  5.  2. 4.5. 
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5.3  ALTKRNATE  USES  OF  .SIMl’l  AT01{ 


The  baseline  simulation  eapalulily  deseributl  pia  viuusly  alluw.s  ilic  .system 
software  to  be  exereised  in  I'eal-ti me.  It  al.--o  i>J'  '"s  tin-  eapalulity  to  tirow,  in 

sophistication  of  simulation,  or  in  o\a  rail  pmjtra  t niuiion,  as  net ds  evolve. 

Par.  5.5  identifies  the  growth  elenu  iits  that  v.il.  . , td  the  La.seline  capability. 

These  growth  phases  incol^)o rate  expandtd  nj  P evaluation  teehmques  in  an  orderly 
manner. 

Alternates  to  the  approach  discussed  in  other  sections  consist  of  variations  in 
primary  use  of  the  simulation  facility  and  possible  variations  in  llight  hardware 
simulation. 

5.3.1  Flight  Hardware  Simulation  - Attack  Radar  Set  (ARS) 

Inclusion  of  the  ARS  as  an  operating  element  can  be  accommodated  to  various 
degrees,  depending  on  user  desires.  The  AN/APQ-130  radar  in  the  F-lllD  contains 
digital,  software  influencing  system  interfaces  not  previously  attempted  with  airborne 
radar.  Therefore,  some  degree  of  airborne  hardware  use  would  be  justified  later  in 
the  program. 

At  the  end  of  the  spectrum  opposite  complete  simulation  would  be  the  use  of  an 
anechoic  chamber  with  a positionable  and  otherwise  controllable  radio  frequency 
target.  This  approach  would  not  seem  reasonable  except  when  end-to-end  checkout 
of  the  Air-to-Ground  (A/G)  modes  is  necessary.  In  the  event  that  tltis  becomes 
necessary,  the  only  w'ay  to  thorouglily  verify  the  modes  is  by  making  dynamic  use  of 
the  radar  set.  In  lieu  of  this  approach,  Autonetics  would  recommend  that  final  A/G 
mode  verification  be  reserved  for  flight  test. 

A more  reasonable  alternate  to  be  considered  would  use  the  radar  as  an  operating 
element  except  that  RF  radiation  would  not  bo  implemented.  This  conliguration  would 
exercise  all  of  the  normal  ARS/System  interfaces  and  would  simulate  a target  only. 

The  simulator  would  calculate  rangc-to-checkpoint  (from  present  position/checkpoint 
position  information)  and  anglc-to-checkpoint.  This  information,  with  .\RS  antenna 
position,  would  be  used  to  trigger  and  gate  a radar  target  generator  (video  pulse 
generator  included  in  baseline  simulation  approach)  and  provide  a dynamic  ground  map 
target  that  could  be  used  for  navigation  position  update.  The  simulated  target  could  be 
inserted  directly  into  the  Integrated  Display  Set  (IDS)  where  it  would  be  combined  with 
radar  generated  range  marks  and  cursors. 

During  the  APQ-130  development  and  system  integration,  techniques  and  special 
test  equipment  were  used  to  provide  a remote  target  for  the  radar.  This  approach 
used  a pickoff  from  the  Master  Frequency  Generator  (MFG)  that  w'as  amplified,  routed 
through  waveguide  to  a tower-mounted  horn.  This  RF  energy  was  then  radiated  back 
to  the  radar,  providing  a target  that  was  controllable  in  range,  but  not  in  azimuth  or 
elevation  without  actual  physical  motion  of  either  the  ARS  or  the  tower- mounted  horn. 

During  the  study,  the  possibility  of  remotely  monitoring  the  system  displays  was 
considered.  The  only  approach  that  could  be  taken  with  the  F-lllD  head-up  display 
would  be  to  mount  a camera  at  the  pilot's  normal  eye  position.  The  curved  combiner 
is  actually  the  collimating  lens  and  thus  can  not  be  monitored  from  the  rear  or  above. 
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This  should  not  be  a problem  with  the  Optical  Display  Sight  in  F-lllF.  The 
Multisensor  Display  could  be  remotely  monitored  by  replacing  the  existing  display 
camera  with  a television  camera  and  a suitable  lens  adapter.  During  system  develop- 
ment, a collimated  light  source  was  used  tor  projection  onto  the  combiner  of  the 
head-up  display  for  accuracy  and  stability  checks.  This  source  is  assumed  to  be 
available  at  S.\Lr\i\L\  to  be  used  accordingly. 

5.3.2  Extensions  of  Intended  Use 

During  the  period  that  the  simulator  would  be  available  there  are  a number  of 
potential  uses  beyond  the  initial  software  checkout  application. 

A possibly  very  important  use  would/will  be  as  a training  device  for  Air  Force 
software  engineers.  As  more  use  is  made  of  programmable  airborne  computers,  the 
need  for  these  engineers  will  become  acute  throughout  the  Air  Force.  Training  that 
could  be  accomplished  using  the  critically  programmed  F-111  computers  in  con- 
junction with  the  dynamic  simulator  as  a tool  will  provide  an  excellent  base  of 
experience. 

Essentially  every  aircraft  in  the  inventory  has  experienced  a changing  role 
and/or  mission  through  its  service  life.  As  this  happens  with  the  F-lfl,  the  simu- 
lator would  become  an  invaluable  tool  in  evaluating  the  capability  to  perform  extended 
or  modified  mission  roles.  In  this  same  vein,  changing  roles  would  likely  be 
accompanied  by  airborne  avionics  hardware  replacement  or  substantial  revision. 

These  changes  can  be  quantitatively  evaluated,  prior  to  incorporation,  rather  easily 
using  an  existing  dynamic  simulator. 

A potentially  important  variation  in  intended  use  of  the  simulator  would  allow 
test  similar  to  the  TVT  testing  described  in  Para.  3.2.  The  simulator  would  pro- 
vide the  same  t>pe  of  total  software  simulation  of  hardware  with  the  advantage  that 
programs  within  both  the  GNC  and  WDC  could  be  tested  simultaneously.  This  would 
eliminate  one  of  the  major  disadvantages  of  the  TVT  approach. 

5.4  TRADEOFF  RESULTS 

During  the  conduct  of  the  study,  there  were  four  areas  of  major  concern. 

These  areas  dominated  the  activity  of  the  study  team.  The  four  areas  were: 

1.  The  role  of  the  current  F-111  Integration  Test  Equipment  (ITE)  in  the 
baseline  simulation  system 

2.  What  test  simulation  processing  hardware  to  consider 

3.  How  to  test  and  verify  the  F-111  OFP's  dynamically  without  resorting  to 
software  contamination  to  the  programs  being  tested 

4.  What  subsystems  should  be  simulated  vs  those  to  be  retained. 

It  is  noted  that  these  factors  were  considered  within  the  constraint  that  a digitally 
controlled  simulator  was  justifiable. 
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5.  4.  1 Hole  of  ITK 


The  ITK  was  designed  to  statically  test  MKll  equipments  and  interfaces  and 
non-MKIl  interfaces.  In  addition,  it  provided  Hie  physical  space  to  contain  the 
avionics  equipments  themselves.  It  v,  as  not  intended  to  he  used  for  dynamic  testing 
and  operational  performance  evaluation.  During  the  early  portion  of  tliis  study,  it 
was  learned  that  S.MAMA  would  have  availahle  for  its  use  the  F-111  nosebay  mockups. 
The  use  of  these  mockups  plus  the  fact  that  S.MAMA  already  has  a static  test  capa- 
bility (the  ITE)  led  to  the  following  leasons  why  the  ITE  would  not  be  integrated  into 
the  baseline  simulation  system: 

1.  Extensiv'e  rearrangement  of  MKll  hardware  mounted  in  the  ITE  would  have 
to  be  made  to  optimally  interface  (physically)  with  the  dynamic  simulation 
equipment  and  concept. 

2.  Serial  word  simulators  are  not  representative  of  the  actual  serial  channel 
operation  and  would  require  major  modifications  of  the  ITE  to  make  them 
useable  in  a dynamic  simulation  environment. 

3.  Rewiring  the  ITE  for  the  changes  necessary  to  interface  with  the  dynamic 
simulation  equipment  would  mean  it  would  be  unavailable  for  several  months 
as  a static  test  console  to  check  current  problems. 

4.  The  non- MKll  simulators  in  the  ITE  are  not  adaptable  for  use  by  the  test 
simulation  processors  without  extensive  rework. 

The  ITE  served  its  initial  goals;  namely,  checking  interfaces  and  performing  static 
functional  testing  of  hardware.  Piecemeal  software  testing  was  also  performed  on 
the  ITE  using  the  computer  console  portion.  However,  the  means  to  achieve  collec- 
tive dynamic  testing  and  validation  of  OFP's  and/or  system  performance  cannot  be 
justified  by  modifying  the  ITE.  The  ITE  should  remain  intact  in  order  to  test  new 
equipments  as  they  are  introduced  into  the  system  as  growth  (such  as  LORAN  and 
data  link). 

Should  the  nosebay  mockups  not  be  available  to  SMAMA  for  use  in  tliis  facility, 
two  alternate  approaches  should  be  considered.  The  ITE  could  be  modified  to  px’ovide 
interface  with  the  simulator,  or  a special  set  of  holding  fixtures  and  harness  could  be 
fabricated  that  would  replace  the  nosebay  mockups. 

The  ITE  modification  would  entail  a substantial  amount  of  electrical  modification 
that  would  bring  all  of  the  MKll  and  non-MKIl  signal  interfaces  to  a common  location. 
In  addition  to  the  electrical  changes,  physical  relocation  of  the  controls  and  displays 
would  be  desirable  in  order  to  provide  more  convenient  system  control  by  a single 
operator.  Starting  with  up-to-date  drawings  of  the  present  configuration,  it  is  esti- 
mated that  resources  on  the  order  of  10  man  months  and  $1K  could  accomplish  this 
modification. 

A rather  austere  approach  toward  providing  engineering  lab  t>pe  of  installation 
provisions  for  the  flight  hardware  is  the  second  alternative.  It  is  conceived  that  a 
commercial  bench  or  cart  would  be  obtained  and  modified  to  house  the  airborne 
hardware.  The  modification  would  entail  fabrication  and  installation,  on  the  bench. 
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of  connector  plates,  wiring  racks,  cooling  ducts  and  equipment  tie-down  pro\isions. 

Wiring  would  essentially  reproduce  thr  existing  nosebay  harness,  with  changes 
required  due  to  the  physieuil  layout  ditierenees.  Again,  a cockpit  station  would  pro- 
vide test  opez'ator  interface.  Again,  with  up-to-date  drawings  of  the  existing  installa- 
tion (including  wiring),  resources  on  the  order  of  17  man  months  and  !?'1K  would  be 
required  to  obtain  such  a set  of  fixtures. 

It  is  recommended  that  the  second  approach  be  considered  in  tlte  event  the 
nosebay  mockups  should  not  lx-  available.  This  recommendation  is  made  primarily 
to  keep  the  present  ITli  configuration  intact.  The  second  approach  would  in  essence 
provide  an  additional  facility,  functionally  similar  to  the  nosebay,  rather  than 
changing  the  existing  ITE. 

5.4.2  Choice  of  Test  Simulation  Processors 

With  the  wide  variety  of  commercial  mini  and  medium  size  computer  systems 
on  the  market,  the  selection  of  one  might  seem  awesome.  However,  the  choices 
quickly  converged  on  the  PDP-11  family  for  the  following  reasons; 

1.  SMAMA  has  access  to  most  government  facility  software  packages.  Hence, 
it  seems  logical  to  select  a computer  system  upon  which  this  sottwarc 
could  be  executed.  An  e.xamination  of  the  Digital  Avionics  Iniormation 
System  (DAIS)  from  WPAEB,  Dayton,  Ohio  indicated  that  they  were  using 
the  PDP  family  in  their  hot  bench  concept.  The  software  planned  for  D.\1S 
includes  air  vehicle  dynamic  simulators,  avionic  hardware  simulators,  etc. 

Some  of  these  software  packages  as  well  as  some  interactive  test  tools 
could  be  valuable  to  S.MAMA.  If  nolliing  else,  it  can  become  a library 
source.  WPAEB  (specifically,  the  AE.AL)  has  subcontracted  with  industry 
to  prepare  much  of  the  software  simulations  to  be  run  on  the  PUP  facili- 
ties. An  example  of  one  such  simulator  would  be  for  the  analog  air  data 
computer.  An  examination  of  the  simulators  being  prepared  for  WPAEB 
may  greatly  reduce  the  initial  development  effort,  at  least  for  the  SSS  and 
RWSS  software  packages. 

Additional  software  has  been  developed  for  use  in  similar  A-7  simulation 
by  the  Naval  Weapons  Center,  China  Lake,  California.  This  simulation 
software  as  well  as  data  processing  routines  and  software  needed  to  inter- 
face with  CMAC  would  have  direct  application  to  S.MAMA  with  a PDP-11  \ 

configuration.  ' 

I 

2.  A brief  comparison  was  made  between  the  PDP-11  system  and  another  j 

potentially  viable  candidate.  While  an  exact  duplicate  conliguration  could  ' 

not  be  established,  sufficient  similarity  was  obtained  for  comparitive  | 

purposes.  The  following  conclusions  were  made:  i 

1 

a.  Acquisition  cost  was  approximately  the  same  with  DEC  support  cost  I 

slightly  lower.  j 
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b.  Data  Iran-slcr  l)ci\vi'<  ii  multipk-  (.•ompiitcrs  would  likely  lx;  a problem 
with  the  alleraati'  caudidau"  beeause  neither  a prc'ijrnmniablc  switch 
nor  the  etjuivaleni  ol  the  "Unibiis  Window"  is  available.  With  the 
alleriuite  candidate,  eoinptiier  to  eomixiter  comnuiniealion  is  pos.sihle 
only  through  a DMA  ehanned  and  the  only  peripheral  that  could  support 
both  C'PU's  is  the  disk. 

For  these  reasons  and  the  PDF's  flexible  growth  eapability,  the  choice  has  been  made 
to  recommend  the  PDP-ll/45  as  the  computer  for  the  baseline  simulation  system. 

5.4.3  Collective  OFP  Test  and  Evaluation 

During  the  study,  two  factors  dominated  any  discussion  regarding  the  testing  of 
the  OFP's.  First,  any  digital  test  facility  had  to  lx;  capable  of  testing  the  OFP's 
collectively.  Second,  no  test  and/or  debug  soltware  was  to  be  loaded  into  the  OFP's. 
This  no  contamination  requirement  of  the  software  led  to  the  approach  of  using  the 
Computer  Monitor  and  Control  Unit  and  the  I/O  Data  Monitor  Unit.  These  units  will 
be  capable  of  "listening"  to  the  activity  on  the  external  and  interal  buses  of  the  4PI 
computers. 

An  examination  of  the  presently  available  methods  for  verifying  operation  of  the 
flight  programs  was  made.  First,  each  program  (GNC,  W DC,  NCU)  is  tested  in  a 
stand-alone  configuration  called  Tape  Verification  Test  (TVT).  Next,  the  three 
programs  are  integrated  in  a static  compatibility  demonstration  test  using  the  ITE. 

In  this  test  the  three  programs  are  integrated  once  during  a free  inertial  run.  For 
subsequent  demonstration  tests,  the  NCU  does  not  participate.  Hence,  neither 
method  ever  integrates  the  three  OFP's  such  that  they  approach  the  operational 
environment.  The  baseline  simulation  system  described  in  Para.  5.  2 would  alle- 
viate this  situation.  It  is  noted  that  the  NCU  has  not  been  treated  (test-wise)  as  has 
the  GNC  and  WDC.  This  has  been  done  because  of  the  dedicated  function  of  the  NCU. 
Since  the  Inertial  Reference  Unit  (IRU)  will  be  digitally  simulated  and  the  NCU  outputs 
will  be  accessible  to  the  test  simulation  processors,  a complete  closed  loop  check 
can  be  performed  on  the  navigation  computer  flight  program. 

5.4.4  F-111  Subsystems  - Simulation  vs  Actual 

There  arc  three  basic  categories  of  F-111  subsystems.  These  are  computers, 
interactive  devices  (controls  and  displays),  and  sensors.  Since  it  is  the  goal  to  test 
and  validate  the  OFP's  being  executed  in  their  natural  habitat,  all  digital  computers 
will  be  retained.  These  include  the  GNC,  WDC  and  NCU.  For  the  FB-lllA  system 
only,  the  SRAM  computer  would  also  be  retained.  Besides  these  digital  computers, 
there  are  also  analog  computers.  Of  these,  only  two,  the  Air  Data  and  flight  director 
computers,  have  any  real  significance  to  the  problem  at  hand.  Since  the  fliglit  director 
computer  interfaces  with  analog-type  controls  and  di.splays  (such  as  HSI  and  ADI),  and 
these  man-machine  devices  will  not  be  simulated,  the  flight  director  will  bc'  retained 
also.  A major  reason  is  the  complexity  of  the  nonlinear  filters  and  association  of 
these  filters  with  air  vehicle  characteristics.  However,  the  air  data  computer  is 
different.  It  processes  sensor  data  such  as  is  obtained  from  temperature  probes 
and  pitot  tubes.  Since  an  atmospheric  model  will  lx;  mechanized  digitally,  it  follows 
that  this  analog  computer  should  be  simulated.  The  outputs  would  be  routed  over  the 
UNIDUS  to  the  Simulator  and  Switching  Unit.  Here,  they  will  be  conditioned  and  then 
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transferred  to  the  same  interfaces  in  the  nosebay  mockup  as  the  actual  analog 
computer.  Further,  this  mechanization  can  be  used  for  all  three  F-111  systems' 
with  little  or  no  changes. 

The  interactive  devices  are  separated  into  controls  and  displays.  All  display 
devices  (analog  or  digital)  will  be  retained.  The  control  devices  (e.g.  , entry  panels, 
SMS  panels,  etc.  ) will  be  retained  also.  However,  these  devices  are  used  by  the 
operator  to  control  modes  and  function  selection.  Therefore,  during  simulation  runs 
(whether  pre- canned  or  manual  control  using  the  stick  and  throttle),  the  capability  to 
simulate  these  panel  functions  and  interfaces  is  required. 

In  general,  all  major  sensors  will  be  simulated.  Moreover,  the  intent  is  to 
achieve  functional  and  interface  compatibility.  Of  all  the  sensors,  the  Inertial 
Reference  Unit  (IRU)  and  the  Attack  Radar  Set  (ARS)  pose  the  biggest  efforts.  It  is 
recommended  that  an  IRU  model  be  developed  which  initially  simulates  a perfect 
sensor.  However,  provision  to  incorporate  errors/noise  of  various  t^pes  would  be  a 
growth  item.  The  model  will  be  capable  of  closed  loop  operation.  On  one  side, 
acceleration  stimuli  will  come  from  the  air  vehicle  si.x  degree-of-freedom  model. 

On  the  other  side,  the  NCU  will  provide  the  applicable  gyro  toiquitw  signals  to  main- 
tain a 'level  simulated  platform"  in  inertial  space.  This  will  become  the  primary 
position,  velocity  and  attitude  sensor  of  the  simulation  system  during  dynamic  test 
and  evaluation. 

The  ARS  will  include  two  kinds  of  mechanizations.  First,  the  ARS  will  be 
simulated  to  provide  the  capability  to  display  a synthetic  target  on  the  applicable 
displays.  At  least  the  radar  cursor  mechanization  will  be  simulated  such  that  cursor 
laying  is  possible  using  the  tracking  handle.  Second,  it  will  be  possible  to  use  the 
actual  ARS  hardware  and  inject  RF  stimulations  under  test  simulation  processor 
control.  The  former  mechanization  will  be  used  for  dynamic  system  simulations. 

A unique  situation  exists  with  Radar  Homing  and  Warning  (RH  and  W)  equip- 
ment. The  equipment  will  not  be  included  in  Phase  I nor  will  the  equipment  be  sim- 
ulated per  se.  It  is  desired,  however,  to  have  a visual  air-to-ground  capability  in 
the  baseline  system  and  this  capability  can  In?  provided  by  using  the  normal  RH  and  W 
threat  warning  symbol  on  the  HUD  and  the  ODSS  to  represent  a visual  target.  This 
symbol  will  be  enabled  by  simulating  the  input  discretes  that  normally  would  be 
generated  in  the  RH  and  W equipment.  The  azimuth  and  elevation  inputs  that  would 
normally  come  to  the  avionics  from  the  RH  and  W equipment  will  simulate  the  location 
of  a visual  target.  This  will  allow  simulation  of  visual  modes  using  the  normal 
visual  displays. 

5.  5 F-111  SIMULATION  SYSTEM  DEVELOPMENT 

The  buildup  of  the  F-111  simulation  system  has  been  partitioned  into  phases. 

The  items  to  be  developed  and  delivert'd  for  Phase  1 will  form  the  baseline  simulation 
system  described  in  Para.  5.  2.  This  section  summarizes  the  development  task  for 
Phase  1.  In  addition,  hardware/software  for  use  in  later  development  phases  are 
enumerated.  Order  of  magnitude  cost  and  schedule  data  are  presented  for  Phase  1. 

An  assumed  go-ahead  for  estimating  purposes  is  1 January,  1974. 


5.5.  1 Phase  1 - Baseline  System  Simulation  Development 

The  primaiw  goal  lor  Pha.se  1 is  l-'-lll  test  and  evaluation  using  dynamic 
simulation  techniques.  There  are  four  areas  to  be  covered.  These  are; 

1.  Actual  hardware  vs  simulation  for  each  F-111  system 

2.  Software  to  support  the  testing  of  F-111  systems 

3.  Unique  F-lll-to-test  simulation  processor  interfacing  hardware  to  be 
developed 

4.  The  test  simulation  computer  system  to  be  procured  by  SMAMA. 

Before  pursuing  each  of  these  areas,  basic  assumptions  are  listed. 

1.  All  models  initially  developed  will  assume  a perfect  environment.  Error 
and  noise  source  injections  will  be  considered  a growth  item. 

2.  Existing  models,  where  available,  will  be  used  in  the  development  cycle. 
This  is  especially  true  where  the  models  are  currently  in  use  at  other 
government  facilities  where  the  PDP  - family  of  computers  is  used. 

3.  Dynamic  simulation  capability  will  lake  precedence  over  static  testing. 

4.  Initial  simulation  system  buildup  will  emphasize  MK  II  problem  solving  and 
system  evaluation  over  non-MK  II  avionics  and  aircraft  problems. 

5.  Two  simulation  systems  will  be  developed.  One  will  handle  the  F-lllD 
while  the  other  will  handle  both  the  FB-lllA  and  F-lllF  systems. 

6.  No  restrictions  in  physical  size,  weight,  power  and  cooling  are  anticipated. 
The  emphasis  for  new  interface  hardware  will  be  on  reliability  and 
modularity  to  accommodate  growth. 

5.5. 1.1  Actual  vs  Simulated  Hardware 

Tables  5-1  and  5-2  list  the  major  hardware  items  associated  with  each  of  the 
three  F-111  systems.  The  tables  indicate  which  hardware  will  be  simulated  and/or 
not  simulated.  An  indication  of  Phase  1 applicability  is  shown.  The  meaning  of  the 
notes  indicated  are  defined  below. 


Note  (1)  - The  J- BOX  primarily  routes  attitude  signals  from  the  IBU  and  AFRS 
to  multiple  users.  Since  these  two  sensors  will  be  simulated,  the  inicrtace  into  the 
J-BOX  will  come  from  the  simulation  and  switching  unit  defined  in  the  baseline  system 
discussion.  (See  Figure  5-3. ) 


Note  (2)  - These  items  must  be  capable  of  being  switched  in  the  simulation  and 
switclting  unit.  The  status  of  all  switches,  buttons,  etc.  will  Ixi  alterable  (ither  from 
pre-canned  mission  setups  or  via  the  operator  control  keyboard/monitor  unit.  When 
not  being  controlled  from  the  test  simulation  system,  the  actual  hardware  item  will 
interface  directly  as  normal. 
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30.  Accplerometer  Transmitter  ACC  XTR  X X 

31.  Radar  Altimeter  Set  HAS  X X 

32.  Terrain  Following  Radar  TFH  X X X(4) 

33.  Flight  Director  Computer  FDC  I X 


No(e  (3)  — These  two  air  veliicle  controls  will  bo  included  in  the  simulation 
facility.  They  are  a roa.sonable  facsimile  of  the  actual  controls  and  interface  (with 
force  or  position  transducers)  directly  with  the  simulation  and  switching  unit  for  input 
to  the  support  simulation  processor. 

Note  (4)  — itolh  the  ARS  and  TFR  will,  in  certain  tests,  require  the  actual 
hardware  to  be  used.  In  thf.'se  cases,  stimulations,  under  test  simulation  processor 
control,  will  be  used.  This  capability  is  a grow  th  item  for  later  phases. 

Note  (5)  - It  is  not  the  intention  to  simulate  the  entire  SRAM  weapon.  How’ever, 
certain  functions  such  as  targeting  and  platform  alignment  may  be  desirable  for  future 
phases. 

From  Tables  5-1  and  5-2,  two  immediate  conclusions  are  drawn.  First,  there 
is  great  commonality  of  hardware  among  the  three  systems.  Hence,  interfaces  and 
software  can  be  prepared  once  and  used  across  the  board  with  little  or  no  modifica- 
tion. Second,  the  Phase  1 baseline  system  will  comprise  about  90  percent  of  the  full 
F-111  dynamic  simulation  capability.  Hence,  one  should  not  view  the  multiphased 
approach  as  starting  small  and  building  accordingly. 

5.  5. 1.  2 Simulation  System  Software 

The  software  falls  generally  into  three  categories,  namely,  that  to  be  (1) 
purchased,  (2)  developed  and/or  modified  from  existing  software,  and  (3)  acquired 
from  other  government  agencies.  Even  though  actual  program  modules  will  not  be 
directly  useable,  (except  for  those  purchased),  the  functional  requirements,  logic, 
and  mathematical  algorithms  will  be  of  immediate  value. 

5.5. 1.2.1  Purchased  Software.  These  software  packages  will  include 
peripheral  handlers  and  computer/peripheral  self  test  modules  for  the  PDP-11/-15 
test  simulation  system.  In  addition,  the  real  time  system  e.xecutive  (RSX-llD)  will 
be  purchased.  An  assessment  will  then  be  made  as  to  its  ability  to  fulfill  the 
Executive  Operating  System  requirements  discussed  in  Para.  5.  2.  2.  A hybrid  is 
anticipated  with  some  RSX-llD  features  merged  with  requirements  unique  to  the 
simulation  system  tasks  to  be  performed.  For  example,  memory  management  does 
not  appear  to  offer  significant  advantages  for  the  simulation  system.  On  the  other 
hand,  a good  deal  of  inter-PDP  traffic  will  be  necessary.  This  implies  a synchroni- 
zation between  the  two  test  computers  to  ensure  timely  and  repeatable  results. 

5.  5. 1.2.2  Developed/Modified  Software.  The  primary  software  items  to  be 
develc^cd  are: 

1.  Man/Machine  Interactive  System 

2.  Canned  Mission  Profiles  with  Breakpoints  for  Recycling 

3.  F-111  Subsystem  Interface  Simulators 

The  Man/Machine  Interactive  System  includes  modules  to  communicate  with  the 
Computer  Control  and  Monitor  Unit  and  the  I/O  Data  Monitor  Unit  among  others.  The 
canned  mission  profiles  will  interface  with  the  Real  World  Simulation  System  as  the 
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main  dri\ing  function.  The  subsystem  interface  simulators  will  provide  the  linkage 
between  the  subsystem  model  outputs  and  the  Simulator  and  Switching  Unit  which 
interfaces  directly  with  tlie  Nosebay  Mockup. 

It  is  anticipated  that  all  other  software  modules  will  be  modifications  of  existing 
packages.  These  modifications  either  entail  coding  changes  to  make  the  module 
compatible  to  i-un  on  the  Executive  Qierating  System  or  using  the  existing  require- 
ments, logic  and/or  algorithms  in  order  to  "re-code"  the  module  for  the  new  com- 
puter/en\ironment.  The  following  items  fall  into  the  software  modification  category: 

1.  IRU  Closed  Loop  Model  (with  J-BOX  interface) 

2.  Doppler  Radar  Model  (functionally  compatible  to  the  E-lllD  and  EB-lllA 
systems) 

3.  F-lllD  Attack  Radar  .Model  (jjrovidc  simulated  Air-to-Ground  target 
capability  with  no  Doppler  processing  modes  initially) 

4.  FB-lllA/F-lllF  Attack  Radar  Model  (same  capability  as  F-lllD) 

5.  Central  Air  Data  Computer  and  Angle-of- Attack  Models 

6.  Radar  Altimeter  Set  Model 

7.  Auxiliary  Flight  Reference  System  Model  (with  J-BOX  interface) 

8.  Flux  Valve  Model  (provides  heading  for  IRU  ground  alignment) 

9.  Accelerometer  Transmitter  Model  (pro\ides  normal  acceleration) 

10.  Throttle  and  Control  Stick  Interface  Model 

11.  Real  World-to- Sensor  Model  Interfaces 

12.  Sensor  Model-to-Simulation  and  Switching  Unit  Interfaces 

Acquisition  of  some  of  those  models  (e.  g. , Air  Data  Computer,  and  Radar  Altimeter 
Set)  would  probably  come  from  other  government  agencies  and/or  government  con- 
tractors. Still  others  would  be  available  in  some  form  from  Autonetics  (such  as  IRU 
model).  Those  items  listed  which  indicate  interfaces,  will,  in  general  be  developed. 

5.5. 1.2.3  Government- Furnished  Software.  Assessment  of  the  Navy  A-7 
simulation  facility  at  China  Lake  indicates  that  the  following  software  could  be  used 
as  the  design  baseline  for  the  F-111  simulation  facility: 

1.  6 degree-of-freedom  air  vehicle  model 

2.  3 axis  autopilot  model 

3.  Atmospheric  Model 
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Actually,  the  Navy  has  three  different  air  vehicle  models  with  varied  levels  of 
simulation  realism  (and  complexity).  The  most  complex,  of  these,  alonsj  with  the 
atmospheric  and  autopilot  models  are  currently  pro{;rammcd  on  the  SIGMA  5 com- 
puter and  utilize  about  50  percent  ol  the  CPU  dutj’  cycle. 

5.5.  1.3  I'-lll-to-Test  Computer  Interface  Units 

From  Para.  5.  2,  tlu'ec  pieces  of  hardware  have  been  identified  for  specific 
development.  These  are  necessary  to  enable  the  test  operators  and/or  the  .simulation 
test  system  to  communicate  with  the  F-111  system  under  test.  These  hardware  are: 

1.  Computer  Monitor  and  Control  (CMAC)  Unit 

2.  I/O  Data  Monitor  (lODM)  Unit 

3.  Simulator  and  Stvitching  (SAS)  Unit. 

The  CMAC  unit  interfaces  with  the  4PI  AGE  connector  and  is  based  on  a design  by 
Naval  Weapon  Center  engineers.  The  lODM  unit  interfaces  with  the  4PI  parallel 
channels  (both  PCO  and  ECI).  The  SAS  unit  interfaces  with  the  CS,  4 Pis,  nosebay 
mockup,  and  control  stick  and  throttle.  Figure  5-3  provides  some  insight  into  the 
hookup  of  the  SAS  unit  with  the  F-111  nosebay  mockup.  Data  to/from  the  support 
simulation  processor  will  be  stored  in  a general  SAS  buffer  and  distributed  to  the 
specific  interface  buffers  shown.  Here,  the  applicable  conversion,  and/or  condi- 
tioning \vill  occur  followed  by  the  appropriate  drivers  or  receivers.  Cable  length 
compensation  will  be  provided  as  necessary.  It  is  anticipated  that  the  NCU,  J-BOX, 
TROT  and  CTL  STICK,  CADC,  HAS,  and  ACC  XMTR  interfaces  will  be  similar  if 
not  identical  for  each  of  the  three  F-111  systems. 

5.  5. 1. 4 Test  Simulation  Computer  System 

The  computer  system  recommended  for  the  F-111  Test  Simulation  is  presented 
in  Figure  5-15.  This  configuration  represents  a modification  to  the  Baseline  System 
discussed  in  Para.  5.  2.  The  primary  difference  is  that  the  communication  between 
the  processors  is  established  through  a DAll-F  unibus  window.  This  inteiproccssor 
communication  link  and  shared  peripherals  are  depicted  in  the  figure.  This  config- 
uration will  permit  the  Support  Processor  to  run  as  a task  under  the  real-time 
executive  (RSX-llD)  in  the  Master  Processor.  The  recommended  technique  elimi- 
nates the  requirement  for  the  Support  Processor  to  have  all  the  memory  and 
peripherals  that  would  be  needed  to  support  another  real-time  executive.  This 
approach  will  not  only  reduce  hardware  cost  by  the  elimination  of  expensive  switches 
but  will  also  increase  the  Support  Processor  throughput  due  to  the  reduced  overhead 
of  the  Support  Software.  The  window  extends  the  concept  of  using  the  basic  PDP-11 
dual-port  memory  by  allowing  memories  to  be  made  shareable  or  nonshareable 
dynamically  and  on-line  as  well  as  sharing  the  control  of  peripherals. 

5.5.  2 F-111  Simulation  System  Schedules  and  Cost 

This  section  summarizes  the  preliminary  cost  and  schedule  estimates  required 
to  implement  the  Phase  1 baseline  Simulation  System.  Costs  will  be  estimated  for 
design,  development,  and  test.  Figure  5-16  is  a summary  of  the  schedule  for  Phase  1 


PREPARE  SOFTWARE 


for  thf  F-lllD  System.  Usinu  as  mueli  eommonalily  as  possible,  the  seliedule  for 
the  I-’n-ll  lA/F-1 11 F development  is  shown  in  Figure  5-17.  The  sehcdule  indicates 
that  the  baseline  F-111  simulation  .system  for  all  tiiree  F-111  systems  can  be  demon- 
strated and  made  operational  (Phase  1)  about  18  months  alter  go-ahead.  The  cost 
estimates  arc  discussed  below  according  to  the  categories  shown  in  Figures  5-lG  and 
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5.5.  2.1  Software  Costs 

The  estimate  for  the  software  effort  will  be  based  on  the  tasks  to  be  performed 
for  each  category.  These  categories  are  (1)  data  base  structure,  (2)  subsystem 
models,  (3)  air  vehicle  models,  (4)  man/macliine  interactive  system,  and  (5)  execu- 
tive operating  system.  The  tasks  will  be  estimated  for  these  five  categories  for  the 
F-lllD  first.  Then,  using  as  much  commonality  as  possible,  the  effoil  for  the 
FB-lllA/F-111  F will  be  estimated. 

5.  5.  2. 1. 1 F-lllD  Software.  The  first  category  is  data  base  structure.  The 
tasks  involved  include: 

1.  Organizing  the  disk  pack  into  records  which  will  accommodate,  as  a 
minimum,  test  modules,  f'-lllD  flight  programs  for  the  GNC  and  W DC, 
canned  mission  profiles,  formats  for  displays  and  hardcopy  de\ices  of  the 
test  computer  system,  and  tables  related  to  parameter  conversions,  test 
setup  menus,  etc. 

2.  Organizing  the  local  data  bases  within  each  simulation  computer  to  include 
input/output  data,  intermediate  data,  test  module/cxecutive  interfacing 
tables  and  mission- related  data. 

3.  Document  the  resulting  structure. 

The  structure  selected  will  be  applied  to  the  FB-lllA/F-111  F design  requirements. 
The  manpower  estimate  is  5 MM  and  is  spread  as  follows: 

Mo.  after  go-ahead  1 2 3 4 5 G 

Manpower:  1/2  1111  1/2 

The  second  category  is  subsystem  models.  The  eight  models  noted  below  for  Phase  1 
for  digital  functional  simulation  arc  included  in  this  effort.  It  is  assumed  that  all 
subsystem  models  already  exist  in  some  form.  That  is,  requirements,  algorithms, 
and  logic  can  be  used  along  with  some  subsets  of  specific  code  to  develop  the  sub- 
system test  modules  to  run  on  the  PDP-ll/45.  The  tasks  include: 

1.  Evaluating  the  usefulness  of  existing  models 

2.  Itcworking  mo<lels  as  nt'cessary  to  be  compatible  with  F-111  simulation 
system  requirements  and  air  vehicle  interfaces 


MONTHS  AFTER  GO-AHEAD 


Figure  5-17.  FB-lllA/F-lllF  Development  Schedule 
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3.  Flow  chart,  code  and  checkout  the  resulting  modules  shoit  of  hardware 
integration 

4.  Document  the  resulting  structure. 

The  matrix  below  summarizes  the  estimates  to  perform  the  tasks. 


Subsystem  Model 

MM 

Comments 

1. 

IRU 

8.  0 

Closed  Loop  Provision  to  Later  Add  Noise/Lrrors 

2. 

AFRS 

4.0 

Simple  Model 

3. 

Flex  Valve 

1.5 

Simple  to  Interface  With  IRU 

4. 

DRS 

3.0 

Simple  .Model 

5. 

CADC 

3.0 

Compatible  with  Atmospheric  Model 

6. 

ARS 

5.  0 

Simple  with  Simulated  Ground  Target 

7. 

ACC.  XMTR 

0.  5 

Provide  Normal  Acceleration 

8. 

RAS 

1.0 

Simple  Model 

Total 

26.  OMM 

The  spread  for  these  26  MM  is  shown  below: 

Months  after  go-ahead:  3 4 5 6 7 8 9 10  11  12  13  14  15  16 

Manpower:  33333222  1 1 1 1 l/2  1/2 

The  third  category  is  air  vehicle  models.  As  mentioned  in  previous  paragraphs,  th(* 
software  estimating  baseline  for  the  dynamic  6 deg.  -of-freedom,  3-axis  autopilot, 
and  atmospheric  model  will  be  that  currently  mechanized  at  the  Naval  Weapons  Center, 

China  Lake,  California.  The  major  tasks  include  tailoring  the  package  to  operate 
within  the  executive  operating  system  in  the  PDP-ll/45  test  computer  system.  As 
many  FORTRAN  statements  as  possible  will  be  carried  over.  Specific  adjustments 
will  be  made  for  conversion  of  SIGMA-5  assembly  code  to  PDP-ll/45  assembly  code. 

The  primary  emphasis  will  be  to  minimize  the  duty  cycle  of  tltis  package.  Hence, 
extra  effort  is  estimated  to  perform  analyses  for  this  effort  is  22  MM.  The  man- 
power spread  is  2 men  per  month  from  month  1 through  month  11  (See  Figure  5-16). 

The  fourth  category,  namely  man/machine  interactive  system,  represents  the 
single  biggest  new  software  development  effort.  It  is  this  software  package  with 
which  the  SMAMA  engineers  will  communicate  with  and  control  the  test  simulation 
system.  The  tasks  will  include  as  a minimum:  j 


1.  Keyboard  options  for  control  of  the  test  setups  stored  on  Disk  File 


2.  Keyboard  options  for  control  of  the  F-111  interfacing  hardware 
(1.  e.,  CMAC,  lODM,  and  5AS  units) 


3.  CRT  display  formats  for  all  test  setups  established 

4.  Control  options  for  turning  the  test  system  on  and  initializing 
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k. 


5. 


Line  Primer  data  formats 


6.  Keyboard  options  for  controlling  the  operation  of  the  Support  Simulation 
Computer. 

For  these  tasks  to  be  fully  responsive,  S.MAMA  must  participate  in  the  requirements 
generation.  J’he  estimate  for  ihts  task  is  42  MM.  The  .spread  is  shown  below; 

Months  after  go-ahead:  2 3 4 5 6 7 8 9 10  11  12  13 

Manpower:  333334444  4 4 4 

The  final  software  category  is  the  executive  operating  S3’stcm.  This  effort  will 
primarily  be  to  examine  the  PDP-11/45  real  time  system  executive  and  determine 
its  adequacy  against  the  EOS  requirements.  The  effort  will  require  consultation 
with  DEC  software  system  personnel.  A support  contract  with  DEC  to  cover  this 
activity  appears  feasible.  Assuming  this  DEC  support  and  that  about  50  percent  of 
the  software  currently  used  in  the  PDP-11/45  executive  is  useable,  the  estimate  for 
this  task  is  12  M.M.  The  spread  is  2 men  per  month  for  months  1 through  G inclusive. 

5.5.  2. 1.2  FD-lllA/F-lllF  Software.  Using  common  software  requirements, 
modules,  data,  etc.  generated  from  F-lllD  efforts,  this  estimate  is  considered  to 
be  25  percent  of  the  total  F-lllD  effort.  This  amounts  to  27  MM's.  The  spread  is 
shown  below': 


Months  after  go-ahead.-  7 8 

9 

10 

11 

12 

13 

14  15  16 

Manpower: 

Data  Base  Structure  1 2 

2 

2 

1 

Subsystem  Models 

1 

2 

1 

Air  Vehicles  .Models 

2 

1 

M/M  Interactive  Sys 

2 

2 

2 2 1 . 

Executive  Operating  Sys 

1 

1 

1 

5.  5.  2. 1.  3 Summary  of  Software  Costs.  The  spread  and  total  manpower 
estimate  for  both  F-lllD  and  FB-lllA/F-lllF  software  design  and  development  is 
shown  below.  Note  that  more  software  manpower  will  be  required  in  Para.  5.  5.  2.4 
of  this  section  (namely  "test  and  integration"). 

Months  after 

go-ahead:  1 2 3 4 5 6 7 8 9 10  11  12  13  14  15  16  17  18  Total 

Manpower: 

' F-lllD  4-1/2  8 11  11  11  V'-l/2  9 8 8 8 7 5 4 1 1/2  1/2  107 

FB-lllA/F-lllF  123334532  1 27 

MM 

5.  5.  2.  2 F-111  Interface  Hardware  Costs 

Hardware  that  will  provide  the  direct  simulator  interface  with  the  F-111  air- 
borne hardw'are  and  the  monitoring  and  control  of  the  OFP  evaluation  has  been  dis- 
cussed previously.  This  hardware  consists  of:  (1)  Simulation  and  Switching  (SAS) 

Unit  (including  partial  analog  simulation  of  the  ARS),  (2)  I/O  Data  Monitoring  (I/O  D.VI) 
Unit,  and  (3)  Computer  Monitor  and  Control  (CMAC)  Unit.  Estimated  cost  of  these 


units  to  provide  the  baseline  capaljility  consists  of  design,  tabrication  and  test  of  a 
first  (F-lllD)  unit  and  fabrication  and  test  of  a second  (FB-l  11  A/F-Jl  1 F)  unit.  Tlie 
l/O  DM  and  CMAC  designs  will  not  change  between  the  first  and  second  uiaits.  Addi- 
tionally, no  design  cost  is  associated  with  the  CMAC  since  the  government  has  an 
existing  design  (MVC,  China  Lake).  Summarizx'd  cost  for  these  units  are  presented 
in  Table  5-3.  ) 


Table  5-3.  Estimate  of  F-111  Interface  Equipment  Cost 


1st  Unit  (F-lllD) 

2nd  Unit 

(FB-lllA/F-lllF) 

Labor 

Parts,  Material,  Etc. 

Labor 

Pai’ts,  Material,  Etc. 

Equipment 

(Manmonths) 

($) 

(Manmonths) 

($) 

SAS 

42.0 

87,500 

16.  0 

77, 000 

I/O  DMU 

10,5 

14,400 

3.0 

6,400 

CMAC 

5.0 

3,  300 

1 

3,5 

3,  300 

Total 

57.5 

105,200 

22.5 

86, 700 

Development  of  these  equipments  is  compatible  with  the  schedule  presented  as 
Figures  5-16  and  5-17. 

5.  5,  2.  3 PDF  - 11/45  Test  Computer  System  Cost 

Estimated  cost  for  each  clement  of  the  Test  Computer  System  is  presented  as 
Table  5-4.  List  price  for  each  of  the  F-lllD  and  FB-lllA/F-111  F Test  Computer 
system  is  $239,  355.  Original  Equipment  Manufacturer's  Discount  available  to 
Rockwell  International  would  reduce  that  price  by  $38,  381.  A maintenance  contract 
for  the  listed  equipment  would  total  $1,794  per  month. 

It  is  noted  that  this  price  would  include  real-time  computer  software  and 
computer/peripheral  system  integration.  Software  to  be  provided  would  include 
background/foreground  resident  executive,  FORTRAN  IV  compiler,  MACRO  assem- 
bler, batch  background  monitor  and  utility  programs.  The  unibus  window  handler  is 
not  supported  under  the  supplied  software  and  must  be  written  as  part  of  the  specific 
operating  system  software. 

5.  5.  2.4  Test  and  Integration  Costs 

There  are  three  tasks  related  to  test  and  integration.  These  arc  to  demonstrate 
the  operation  of  the  PDP-ll/45  test  computer  system,  to  integrate  the  F-111  inter- 
face hardware  between  the  PDP-ll/45  and  the  nosebay  mockup,  and  to  integrate  tlie 
simulation  software. 
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Table  5-4.  Test  Computer  System  Cost  Breakdown 


Item 

Qty 

Description 

I'nlt 

Price 

Pricf 

Monthly 

Main. 

Extended 

MASTFU  PRCTKSSOn 

1 

1 

ll/45-M\\  loK  1 l/  lij'biH'd  Keal-tlme  System 
wUh  (oroi'r*  untl  and  :roani!  DrocessinR. 

Haniwaic*  fUiatinn  point  nn.i  dual  caMridpe  dtsk 
storage.  Irtcluoes: 

• 11/45-CP  Processor  W ith  32K  parity  (CH) 
core  memory,  memory  management, 
processor  and  extension  mciinting 
cabinets,  autoloader,  real -time  clock 
and  serial  30  CPS  DECwriler 

• MMU-LP  8K  parity  core  memory 

• FPll-B  Floating  point  processor 

• RKll-D  1.2  million  word  DECpack  disk 
unit 

• RK05  1,2  million  word  DKCpack  disk 
drive 

• QJ580-AE  Real'tlme  system  software 
license 

177,260 

$77.  260 

580 

2 

1 

MMll-'LP,  6K  words  900  n/sec  parity  memory 

S.400 

5.400 

35 

3 

3 

DLll-A  20MA  Asynchronous  Line  Interface 

430 

1,290 

16 

4 

3 

VT05B-AA  Alpha, '^numerlc  Keytward  CRT 
Terminal  . 

2.795 

0,365 

66 

5 

1 

TMll^EA  9 channel  Industrial  Compatible 
Tape,  BOO  bpi,  45  fps  with  controller  and 
cabinet 

10,  745 

10.  748 

95 

« 

1 

TUIO'EE  9 channel  Industrial  Compatible  Tape. 
600  bpt,  45  ips.  Includes  cabinet 

7,505 

7,605 

70 

T 

1 

PCll,  High  Speed  Paper  Tape  Reader/Punch 

3,900 

3.900 

36 

8 

1 

LPll-KA,  300  tPM  Lln«  Printer,  132  column 

19,  000 

19.  000 

80 

9 

1 

CRH.  300  CPM  Card  Reader 

4.860 

4,  860 

50 

10 

2 

DDll-B,  System  Units 

IBS 

370 

- 

11 

1 

DDll-A,  Untbua  Repeater 

1,  060 

1,  080 

5 

SUPPORT  SIMULATION  PROCESSOR 

It 

1 

ll/50-CP  Central  Processor  with  16K  parity 
M06  memory  plus  16K  parity  core  memory  and 
hardware  memory  management.  Includes  power 
supply,  cabinet,  line  frequency  clock,  muUI'* 
device  auto  loader,  power  fall/reatart,  aerial 
30  CPS  DECwrlter  terminal  and  control,  and 
five  training  credits 

51,070 

51,070 

430 

13 

1 

FPll-B  Floating  Point  Processor,  Performs 
hardware  operations  on  32 -bit  snd  G4-bit  floating 
point  numbers  as  well  as  integer  to  floating 
converaiona. 

5,290 

6,  290 

42 

14 

1 

MSll-BD  Second  M06  Memory  Control,  Controls 
up  to  four  additional  MSlI-BM  or  MSll-BP 
memories. 

1,500 

1,500 

12 

IS 

4 

MSIl-BP,  4K  MOB  memory  with  byte  parity 

6. 200 

20.  800 

160 

COMMON  DEVICES 

16 

1 

DAll-F  Untbua  Window,  High  Speed  Intertwa 
Channel 

6,600 

6,  600 

40 

17 

1 

DT03-FP,  Programmable  Unlbua  Switch 

8,400 

8,400 

75 

18 

1 

Syatem  Integration  Charge 

6,000 

6.000 

- 
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5.5.  2.4.1  Simulation  KciiiipinfiU  Dumorii-ti-niion.  AfUT  the  PDP-l  1/45 
sj’slem  has  been  assembled,  tested  and  inte;;raied  l)y  DEC  personnel,  this  eflorl 
would  demonstrate  final  operation  of  tliis  puieha.sed  hardware/software  system  to 
SiMAMA.  As  a minimum,  all  peripherals,  ineludin;;  the  disk  file,  will  be  exercised 
to  demonstrate  proper  operation.  Compilation  and  execution  of  a typical  I'UU  THAN 
program  will  be  demonstrated.  An  intercomputer  data  transfer  demonstration  will 
also  be  accomplished.  i'he  cost  for  this  di-monslration  is  included  in  the  purchase 
price  of  the  total  PDP-ll/45  system  discussed  in  Para  5.  5.  2.  3. 

5.5.  2.4.2  Interface  Hardware  Integration.  Each  F-111  Interface  Hardware 
Unit  will  be  integrated.  The  C.MAC  and  lOD  .M  units  will  be  integrated  first  on  the 
F-lllD  system.  Once  checked  and  debugged  on  the  F-lllD  system,  the  second  units 
(for  the  FB-1  llA/E'-l IID  system)  will  be  checked  primarily  for  fabrication  problems. 
The  major  integration  effort  occurs  with  the  SAS  units  (both  systems).  The  estimated 
manpower  to  test  and  integrate  these  units  is: 

F-lllD  - Months  After  Go-ahead:  10  11  12  13  14  15  Totals 


ClvIAC  unit 
lODM  unit 
SAS  unit 


FB-lllA/F-lllF 
CMAC  unit 
lODM  unit 
SAS  unit 


1 

2 1 
2 


13  MM 


1/2 
1/2 
2 2 


5 MM 


5,  5.  2.4.3  Checkout  and  Integration.  The  checkout  and  integration  of  the  unique 
test  simulation  software  modules  comprises  this  cost.  From  similar  experience  on 
other  programs  (F-111,  Polaris,  Minuteman),  it  is  estimated  that  one  fourth  of  the 
total  programming  effort  supports  software/hardware  integration.  Hence,  the  esti- 
mate is  27  MM.  The  spread  is  3 men  per  month  from  month  h through  month  17  (See 
Figure  5-16).  The  estimate  for  the  F'B-lllA/F-111  F is  based  on  similar  activity 
with  F-lllD.  This  estimate  is  10  MM.  The  spread  is  2 men  per  month  from 
month  14  through  18. 

5.  5.  2.4.4  Summary.  A summary  of  the  test  and  integration  task  is  shown 
below. 

Months  after  go-ahead:  9 10  11  12  13  14  15  16  17  18  Totals 

F-lllD  356655433  40 

FB-lllA/F-lllF  5 4 2 2 2 15 


55  .MM 


5.  5.  2. 5 Demonstration  Costs 


During  months  17  and  18,  a demonstration  of  all  basic  functions  would  lx?  per- 
formed. This  demonstration  will  certify  that  the  hardware  and  software  perform  the 
operations  dictated  by  the  test  operators.  The  estimate  is  3 MM  for  each  month  for 
the  F-lllDand  FB- 111 A/F-11 1 F respectively. 


5.  5.  2.6  General  Comments 


While  not  specifically  enumerated  as  a cost  item,  the  documentation  ol  hardware 
descriptions  (includini'  operation),  and  software  jiiodiilcs  is  included  in  the  previous 
costa.  However,  it  is  desirable  to  provide  an  overall  users  manual  lor  t’-lll  simula- 
tion system  operation.  This  manual  is  assumed  to  be  written  by  b.MA.MA  personnel 
with  assistance  as  required  from  liie  aiiplicable  contractors.  It  is  estimated  that 
there  would  be  at  least  60  percent  commonality  between  the  F-lllD  manual  and  the 
FB-lllA/F-lllF  manual. 

5.5.  3 F-111  Simulation  System  Growth  (Phase  II  and  III) 

It  is  envisioned  that  all  software  modules  developed  tvlll  be  modular.  The 
capability  to  introduce  noise,  errors,  etc.  into  simulated  subsystem,  airframe,  etc. 
will  be  provided  without  software  redesign.  Also,  the  SAS  unit  will  be  designed  to 
accommodate  growth  for  additional  analog,  serial  and  parallel  interfaces  with  the  DCC 
and  nosebay  mockup. 

5.  5.  3. 1 Phase  II  Growth  (Minimum) 

1.  Astrocompass  Model 

2.  Error/Noise  Injection  Into  Models 

3.  Static  Simulation  of  all  F-111  Panel  Interfaces 

4.  Attack  Radar  Doppler  Processing  Modes  (F-lllD  only) 

5.  Magnetic  Tape  Recorders  (for  data  recording  of  simulated  system  activity 
during  a test.  Data  reduction  would  be  accomplished  using  PDP's  or  other 
large  computer  complex 

6.  Card  Reader  (for  continuous  program  maintenance) 

7.  Paper  Tape  Reader/Punch  (Making  addendum  tapes  for  F-111  field  use) 

8.  Takeoff  and  Landing  Capability  in  Mission  Profiles 

5.  5.  3. 2 Phase  III  Growth  (Minimum) 

1.  SRAM  Missile  Model 

2.  HUD/ODSS  stability  and  accuracy  hardware/software  mechanization 

3.  Automatic  F-111  Problem/Tape  Configuration  Control  maintenance 
5.  6 BASIC  SIMULATION  REQUIREMENT  RATIONALE 

There  is  a basic  shortcoming  in  the  F-111  avionics  software  capability  at 
SMAMA.  This  shortcoming  is  the  lack  of  a capability  to  dynamically  evaluate  new  or 
revised  operational  flight  software  and  the  solutions  to  software/hardwarc  problems. 
This  lack  makes  it  very  difficult  for  SMAMA  to  thoroughly  evaluate  software  prior  to 


r 
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release  to  operating  commands.  Witli  a dynamic  simulation  capability,  significant 
benefits  will  be  derived  in  the  areas  discussed  below. 

5.  6, 1 Improvements  in  Completeness  of  Checkout 

The  simulation  facility  proposed  in  tliis  study  will  provide  AFLC/SNIAMA  the 
necessary  test  capability  for  FB-111,  F-lllD  and  F-lllF  system  and  software  mainte- 
nance. This  equipment  overcomes  the  test  limitations  imposed  by  the  static  capability 
of  the  existing  ITF  facilities.  Improvements  in  completeness  of  checkout  that  will 
result  from  the  recommended  facility  are  attained  because  dynamic  simulation: 

1.  Allows  dynamic  evaluation  of  all  modes  on  ground 

2.  Allows  interactive  use  of  all  three  computers  in  dynamic  situations  - not 
possible  statically 

3.  Allows  both  man-in-thc-loop  search  for  anomalies  and  preprogrammed 
flight  profile  accuracy  evaluation 

4.  Allows  detailed  examination  of  conditions  causing  anomalies 

5.  Eliminates  aircraft  scheduling/availability  problems 

6.  Allows  exact  (if  known)  and  repeatable  reproduction  of  conditions  in  which 
flight  problems  arc  experienced. 

The  requirement  for  an  increased  test  capability  resulting  in  improvements  in 
the  completeness  of  checkout  was  established  by  examining:  (1)  the  F-111  weapon  sys- 
tem maintenance  problem,  (2)  the  integration  test  equipment  (ITE)  inadequacies, 

(3)  need  for  improved  test  facilities,  and  (4)  required  test  facility. 

5.6. 1.1  The  F-111  Weapon  System  Maintenance  Problem 

J 

F-111  systems  are  composed  of  numerous  advanced  subsystems  which  are 
integrated  into  the  most  sophisticated  avionic  equipment  available  today.  The  com-  ' 

plexlty  of  the  FB-lllA,  F-lllD  and  F-lllF  avionics  systems  required  that  numerous  i 

functions  within  the  airborne  systems  be  automated  and  removed  from  continuous 
operator  control,  manipulation  and  even  observation  and  access.  This  automation  was 
provided  by  the  incorporation  of  three  separate  digital  computers.  The  computer 
control  of  the  various  subsystems  and  functions  is  provided  in  the  GNC  and  WDC  by  i 

executing  permanently  stored  programs.  In  order  to  perform  the  required  control  j 

with  the  available  memory  and  computing  capability,  extremely  efficient  programs  ; 

were  developed.  The  natural  result  is  that  the  computer  flight  programs  arc  generally  { 

inflexible.  Any  changes  desired  to  the  program  require  detailed  analysis  and  usually  i 

major  program  modifications  to  provide  rt:quired  memory  space  for  the  addition  or 
change.  The  high  degree  of  computer  utilization  combined  with  extremely  efficient 
flight  programs  requires  that  a systematic  and  timely  solution  to  problems  be  devel- 
oped. Figure  5-18  outlines  steps  taken  in  the  past  in  solving  a tipical  field  problem 
involving  a flight  program  change.  This  flow  is  not  unique  and  is  presented  to  indi- 
cate areas  in  which  ground  test  facility  use  is  either  required  or  would  be  useful. 

Steps  4 through  8 represent  those  areas  within  the  OFP  revision  cycle.  The  tjpe  of 
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Figure  5-18.  Typical  F-111  Problem  Solution  Sequence 
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facilities  and  the  deforce  of  automation  are  indicated  in  following;  sections  by  reviewing 
in  detail  what  test  functions  must  Ite  provided  to  enable  a timely  solution  to  tjpieal 
expected  system  engineering  problems. 

5.6. 1.2  Integration  Test  Equipment  (ITK)  Inadequacies 

Capabilities  of  the  ITE  were  examined  to  d(Uermine  its  usefulness  in  a long 
term  software  maintenance/development  program.  The  Integration  Test  Equipment 
(ITE)  is  special  test  equipment  which  was  initially  designed  to  accomplish  the  overall 
functional  checkout  including  development  and  veritication  of  operational  computer 
programs.  In  general,  this  equipment  statically  simulates  all  extenial  interface  sig- 
nals required  for  avionic  system  operation,  provides  the  capability  to  monitor  digital 
and  analog  signals  as  tests  arc  performed,  and  control,  fill,  and  readait  the  digital 
computers  in  each  system.  The  ITE  performs  no  automatic  testing.  Elight  program 
inputs  are  initialized  by  manually  setting  sensor  inputs  and  switch  position  on  ationic 
subsystem  hardware  and  simulators.  Verification  of  system  test  response  is  obtained 
by  observing  static  ITE  displays  and  outputs  of  the  avionic  subsystem  hardware.  In 
spite  of  the  ITE  inadequacies  presented  here,  the  capabilities  within  the  ITE  arc 
valuable  and  useful.  It  must  be  kept  in  mind  that  the  ITE  is  the  tool  that  has  been 
used  since  the  beginning  of  the  F-111  program  to  integrate  and  test  both  hardware 
and  software.  Many,  many  problems  were  identified  and  solved  using  this  equipment 
with  techniques  and  approaches  still  available.  Of  primary  concern  in  the  discussion 
of  inadequacies  are  the  subtle  problems  that  elude  detection  on  the  ITE  and  i-esult  in 
operational  shortcomings  and  nagging  problems. 

Specific  limitations  of  the  existing  F-111  avionic  test  equipment  (ITE)  are  listed 
in  Table  5-5.  These  limitations  can  be  segregated  into  the  following  general  categories: 

1.  Limited  input  signal  control  — only  one  serial  data  word  can  be  set  up  and 
transferred  at  any  one  time.  No  real-time  data  entry  can  be  performed. 

2.  Lack  of  monitoring  or  data  gathering  capability. 

3.  Inability  to  create  realistic  dynamic  flight  conditions. 


Testing  of  the  complex  F-111  avionic  system  requires  continuous  positive  control 
over  the  F-111  flight  hardware.  This  control  includes  the  capability  to  stimulate  the 
hardware  to  a degree  sufficient  to  create  an  actual  system  environment.  The  present 
ITE  equipment  provides  a limited  input  capability  which  results  in  an  artificial  "static" 
test  situation.  This  capability  is  inadequate  to  create  test  situations  necessary  to 
precipitate  solutions  to  the  majority  of  existing  or  expected  problems. 

5.6. 1.3  Need  for  Improved  F-111  Test  f’acilities 

The  high  degree  of  automation  in  the  F-111  weapon  systems  combined  with  the 
large  number  of  sophisticated  subsystems  makes  system  problem  solutions  difficult. 
This  difficulty  results  from  the  extensive  interaction  of  individual  subsj’stcms  through 
the  digital  computer  complex  via  the  extremely  efficient  flight  programs.  A review 
of  existing  and  expected  hardware  and  software  problems  has  revealed  that  a dynamic 
test  capability  must  be  provided.  This  dynamic  test  capability  is  requin'd  to  provide 
(1)  rapid  reconstruction  of  field  problems,  (2)  isolation  of  problem  sources. 
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Table  5-5.  Specific  TfE  Liadequacles 


ITE  Test 

Element/Function 


1)  Serial  Word 
Simulator  (SWS) 


2)  Serial  Word 
Monitors  (SWS) 


3)  Computer/ 
Converter  Set 
Interface 
Monitoring 

4)  Computer  Data 
Entry 


5)  Simulated 
External  Input 
Signals  (Velocity, 
Altitude,  Heading, 
Pitch,  etc.) 

6)  INS,  ARS, 

Doppler  Radar 
and  Astro 
Con^ass  Static 
Test  Set-up 

7)  Computer 
Monitoring 


Inadequacies 


1)  a.  Serial  word  simulators  are  limited  to  simulation  of 

valid  data  for  only  one  word  at  a time.  This  results 
in  time  consuming  operations  to  input  multiple  data 
and  in  a number  of  cases  does  not  provide  valid  test- 
ing since  actual  data  transfer  rates  are  not  being  met. 

b.  Data  entry  is  in  difficult-to-use  bit  patterns  instead 
of  desirable  engineering  units. 

2)  a.  Serial  word  monitors,  (SWM),  are  limited  to  monitor- 

ing only  one  word  at  a time.  Only  three  SWMs  are 
available  per  ITE.  Data  words  are  in  binary  bit 
patterns. 

b.  SWM  can  only  be  put  in  freeze  mode  manually  to 

retain  and  display  the  last  input  received.  It  is  desir- 
able to  monitor  the  fast  changing  data  at  critical  limes 
which  can  only  be  indicated  by  a discrete  or  strobe 
signal. 

3)  Visual  monitoring  equipment  is  not  available  at  computer/ 
converter  set  interface.  Visual  aJid  perhaps  hard  copy 
recording  should  be  provided  at  all  subsystem  interfaces. 
Controls  to  freeze  data  at  critical  times  should  be 
included. 

4)  Programmers  key-in  data  in  the  wrong  memoi-y  locations. 
Correcting  the  data  in  these  locations  might  only  be 
accomplished  by  a new  memory  load.  A hard  copy  print- 
out should  be  provided  for  all  memor7  key-ins. 

5)  Manual  entry  results  in  step  data  changes  instead  of  the 
smoothly  varying  real  world.  Signals  cannot  be  coordi- 
nated  to  simulate  the  actual  aircral't  dynamics. 


6)  ITE  provides  only  static  operation  of  these  subsystems. 
Static  operation  greatly  limits  overall  system  testing  and 
evaluation.  Critical  system  modes  such  as  designation, 
target  tracking  and  navigation  cannot  be  tested. 

7)  The  ITE  test  set-up  does  not  allow  the  use  of  peripherals 
(printers,  tape  units,  etc. ) for  data/program  monitoring 
without  the  introduction  of  contaminating  data  monitoring 
programs  to  the  actual  flight  program. 


(3)  development  and  evaluation  of  protilem  .solutions,  and  (‘1)  tlw.  on-line  anti  real-time 
dynamic  verification  of  flij^ht  tapt  chan^e.s  prior  to  and/or  in  lieu  of  flight  testing. 

An  examination  of  over  300  past  and  present  problems  in  the  "S.MA.MA  I’-lll 
Problem  Book"  was  made.  Two  major  conclusions  were  reached.  First,  between 
25  and  40  percent  of  the  problems  for  all  three  F-111  systems  will  n'cjuire  some  form 
of  dynamic  test  configuration  in  order  to  develop  and/or  \alidate  a solution.  II  simu- 
lation is  not  available,  flight  testing  will  be  exten.sivcly  required.  .Se-cond,  about 
80  percent  of  the  problems  require  the  alteration  of  the  operational  flight  programs. 
Moreover,  these  alterations  will  primarily  add  words  to  computers  that  are  08  percent 
filled  in  order  to  effect  the  solution. 

AFLC/SMAMA  presently  does  not  have  the  capability  to  provide  the  required 
dynamic  weapon  system  testing  necessary  for  timely  solutions  to  field  problems  and 
flight  program  revisions.  Failure  to  obtain  these  dynamic  test  facilities  will  result 
in  excessively  high  maintenance  costs,  slow  response  times  to  field  problems  and,  in 
general,  will  result  in  F-111  weapon  systems  operating  in  the  field  below  designed 
levels. 

AFLC/SMAMA  F-111  system  engineering  responsibilities  will  include  flight 
computer  program  maintenance,  investigation  of  mechanization  problems  (both  hard- 
ware and  software)  and  implementation  of  new  modes  and  hardware.  To  meet  these 
responsibilities,  SMAMA  must  have  facilities,  test  equipment  and  a team  of  skilled 
personnel  who  are  capable  of  performing  all  the  functions  necessary  to  define,  develop, 
verify  and  implement  change  to  flight  programs  and  perform  rapid  system  mechaniza- 
tion changes.  Key  to  this  effort  is  the  basic  system  test  and  evaluation  facilities. 

The  degi-ee  of  automation  and  sophistication  in  the  test  and  evaluation  facilities  will 
determine  the  timeliness  of  problem  solutions,  cost  in  manpower,  the  co.st  of  flight 
test  support  required,  and  will  ultimately  determine  the  operational  quality  (capability, 
accuracy,  etc. ) of  the  FB-lllA,  F-lliD  and  F-11]  F weapon  systems.  A study  into 
the  total  F-111  system  maintenance  problem  indicates  the  need  lor  a degree  of  test 
equipment  automation  above  that  presently  available  with  the  static  ITK  test  stations. 

To  understand  the  need  for  a simulation/computer  aided  test  facility,  one  must  first 
review  the  tasks  involved  in  performing  system  level  maintenance  on  the  FU-lllA, 
F-lllD  and  F-lllF  weapon  systems. 

5.6. 1.4  Required  Test  J’acility 

As  the  F-111  weapon  system  matures,  the  problems  encountered  become  more 
complex,  difficult  to  solve,  and  time  consuming.  For  example,  problems  in  weapon 
trajectory  computations  almost  always  involve  several  analysis/test/evaluate  iteration 
cycles  before  satisfactory,  accurate  solutions  are  obtained.  Large  amounts  of  data 
must  be  collected  for  problem  identification.  Also,  F-111  problems  involving  naviga- 
tional accuracy  require  statistical  processing  of  large  amounts  of  test  data.  Solution 
of  navigation  steering  and  weapon  delivery  steering  type  problems  requires  a dynamic 
man-in-lhe-loop  simulation  of  the  F-111  aircrafts.  In  order  to  solve  these  problems, 
test  facilities  must  provide  continuous  positive  control  over  the  F-111  flight  hardware 
under  test.  'I’his  control  includes  stimulation  or  input  data  generation,  monitoring  or 
data  gathering,  and  evaluation  of  data  analysis.  An  F-111  digital  simulation  facility 
would  provide  the  direct  control  necessary  to  develop  and/or  veilfy  solutions  to  oper- 
ational problems.  This  facility  would  provide  the  dynamic  system  environment  neces- 
sary for  investigation  and  evaluation  of  problem  solutions  and  would  be  capable  of 


automatic  data  generation,  data  gathering,  and  data  analysis.  Some  of  the  features  of 
this  F-111  digital  simulation  facility  necessary  for  rapid  problem  solutions  are  as 
follows: 


5.  6.  1.  4. 1 Stimulation  or  Input  Data  Generation.  An  impoitani  aspect  of  the 
F-lll  problem  solutionis  the  measurement  of  the  weapon  systems  respoase  to  stimu- 
lation. Important  factors  in  the  stimulation  phase  are  the  choice  of  the  points  of  data 
injection  into  the  system  and  the  approach  to  data  geixjration.  The  pre.sently  available 
F-lll  ITE  equipment  has  limited  data  stimulation  capability.  This  shortcoming  is 
overcome  by  using  digital  simulation  equipment  involving  a test  computer.  Real-time 
data  and  dynamic  flight  profiles  would  be  supplied  as  input  stimulations.  This  capa- 
bility would  protidc  for  the  creation  of  a realistic  system  operational  environment 
instead  of  the  artificial  "static"  situation  now  provided  with  the  existing  test  equipment. 

5.  6. 1.4.2  Monitoring  or  Data  Gathering.  The  digital  test  or  simulation  facili- 
ties would  allow  data  gathering  in  real-time.  Test  computer  control  would  enable 
direct  control  of  the  F-lll  weapon  system.  During  problem  analysis  and  debugging, 
flight  programs  could  be  halted  and  examined  at  predetermined  or  sen.sed  program 
states.  This  capability  would  greatly  facilitate  problem  isolation  and  is  not  now  avail- 
able with  the  existing  ITE  test  equipment. 

5.  6. 1.  4.  3 Creation  of  Unique  Problem  States.  It  is  possible  under  digital  simu- 
lation to  create  computer  program  and  llight  situations  that  are  unlikely  (low  protm  - 
bllity  of  occurrence),  dangerous,  or  expensive  to  duplicate  under  live  llight  eondiMons. 
The  digital  simulation  facility  can  be  used  to  create  artificial  program  states  to  elieck 
the  flight  programs  and  flight  hardware  responses  to  error  conditions.  Tltis  capability 
is  not  available  with  the  existing  F-lll  test  facilities. 

Two  important  test  problem  areas  that  require  a dynamic  system  environment 
are  discussed  below: 

5.6. 1.4.4  Collective  Evaluation  of  Flight  Programs.  Each  program  (GNC, 

WDC  and  NCU)  can  be  tested  in  a stand-alone  conliguration.  The  three  programs  can 
also  be  integrated  in  a static  compatibility  demonstration  test  using  the  ITE.  In  this 
latter  test  the  three  programs  are  integrated  only  during  a "free  inertial"  run.  For 
subsequent  demonstration  tests,  the  NCU  does  not  participate.  Hence,  neither 
method  ever  integrates  the  three  flight  programs  such  that  they  approach  the  opera- 
tional environment.  The  F-lll  dual  computer  mechanization  has  a number  of  areas 
of  flight  program  interaction.  This  interaction  includes  GNC  program  inputs  to  the 
WDC  computer  for  w'eapon  delivery  computations:  dual  computer  operation  is  required 
for  self-test  and  backup  mode  operation.  The  dual  computer  synchronization  and 
timing  can  only  be  verified  by  simultaneous  operation  of  lx)th  computers.  The  require- 
ments for  dual  computer  operation  during  an  operational  environment  requires  a 
source  of  external  control  and  monitoring.  This  capability  can  best  be  provided  with 

a digitally  controlled  test  setup  or  simulation  facility. 

5.6. 1.4.5  Man-in-the-Loop  Sequential  Testing.  A large  number  of  the  F- 1 11 
system  modes  require  that  the  crew  sequence  through  a number  of  operating  condi- 
tions or  steps  in  response  to  a dynamic  or  changing  set  of  system  parameters.  In 
general,  these  steps  must  be  exercised  in  a systematic  sequence,  usually  within  a 
given  time  period.  Some  of  the  system  modes  requiring  this  crew/hardware  inter- 
action include  target  recognition,  designation,  weapon  delivery  and  manuai  steering. 
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The  evaluation  of  eliangc  s and  optimizalion  to  the'  erew/mechani/alion  parametera 
cannot  be  simulated  or  evaluated  with  a static  test  facililj'.  A means  must  be  provided 
for  real-time  ciueuinj;  oi  me  crew  and  the  measurement  or  evaluation  of  the  resultant 
crew  response.  This  reijuires  dynamie  displays  and  other  hardware  responses  cap- 
able of  simulating  the  actual  dynamic  environment.  Failure  to  provide  dynamic  test 
facilities  for  man-in-the-loop  ijpe  testing  w'ill  necessitate  probh  m solution  by  exten- 
sive flight  testing. 

5.6.2  Cost  Ramifications 

In  order  to  quantize  the  direct  cost  saving  potential  with  an  F-111  dynamic  simu- 
lator, costs,  schedule,  and  performance  confidence  factors  of  a recent  effort  in 
developing  an  updated  operational  flight  program  (OFP)  for  the  F-111 1)  were  examined. 
These  factors  were  then  compared  with  their  expected  equivalents;  had  the  proposed 
dynamic  simulator  approach  been  available. 

The  task  that  was  examined  is  the  contractor/Air  Force  effort  in  converting  the 
PID-4  operational  flight  program,  with  its  identified  operational  and  specification 
problems,  into  an  updated  PID-5  version  (subsequently  identified  as  OFP  112/212) 
designed  to  resolve  the  PID-4  problems.  The  task  had  been  preceded  by  a numl)cr  ol 
previous  similar  OFP  updates  and  thus  the  examined  effort  is  felt  to  represent  a 
typical  update  of  a mature  operational  flight  program  by  experienced  personnel. 

The  subtasks  to  be  performed  were  identified  as  follows; 

Task 

(A)  Problem  Analysis 

Fact  Finding 

Problem  reconstruction  on  available  test  equipment  and 
hardware 

Problem  solution 

(B)  Mechanization  Change  Requirements  Analysis 

Program  optimization 

Definition  of  mechanization  requirements 

(C)  Software/Program  Change  Analysis 

Definition 

(D)  Lab  Evaluation  on  Available  Test  Equipment 

(E)  Initial  Software/Program  Changes 

(F)  Prepare  Test  and  Evaluation  Tapes 

(G)  System  Compatibility  Demonstration  and  TVT 

(H)  Finalize  Software/Program  Tapes 

Sell-off 

(I)  Configuration  Control 
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(J)  ECS/EC  P Documontation 

(K)  Flight  Tc'st 


The  above  subtasks  may  be  groujjed  into  the  lollowing  phases; 

Phase  1 Tasks  A and  B Problem/Solution  Definition 

Phase  2 Tasks  C,  D,  E and  F Implement  Changes 

Phase  3 Tasks  G,  H,  I and  J Static  Test  Verification 

phase  4 Task  K Flight  Test  Verification 

An  examination  of  the  in-house  (contractor)  effort  in  completing  Phases  1 
through  3 indicates  the  following: 


Cost: 

Schedule: 

Performance 

Confidence: 


Average  12  men/month 
Seven  months 


Fair  confidence  that  new  OFP  will  meet  id  I 
requirements  for  operational  use 


An  estimate  of  the  flight  test  effort,  i.e.  , Phase  4,  can  be  made  barsed  on  the 
presently  planned  F-lllD  OFP  DOT  115/215  validation  at  Cannon  Ai'li  (TAC  Project  73 
Alpha  136F).  In  this  validation  effort,  40  sorties  are  planned  requiring  the  commit- 
ment of  six  aircraft,  four  crews,  the  necessary  supporting  maintenance  and  other 
services  and  spanning  one  to  tw'O  months  calendar  time.  It  has  been  previously  esti- 
mated that  an  average  sortie  costs  $14K.  Thus,  it  can  be  estimated  that  t!ie  DOT 
115/215  validation  flight  test  costs  will  be  approximately  $560K  (sustained  by  the 
operational  command). 

With  a detailed  knowledge  of  the  tasks  involved  in  developing  an  updated  opera- 
tional flight  program  utilizing  the  existing  methodology  and  test  equipment,  it  is 
possible  to  make  a reasonable  comparison  to  an  approach  utilizing  the  proposed 
dynamic  simulator.  This  comparison  is  summarized  in  Table  5-6. 

It  is  is  assumed  that  each  of  the  F-111  models,  i.e. , the  D,  F and  FB,  will 
require  one  OFP  update  per  year,  it  is  thus  apparent  that  F-111  OFP  mt'.intenancc 
effort  savings  of  approximately  3[(33-55)  ($/MM)  + (490K)]  s$l,700,000  could  be 
realized  each  year.  Additionally,  the  schedule  improvement  to  four  months  per  air- 
craft model  OFP  would  permit  a continuous  noninterference  full-time  approach  to  the 
programming  update  effort  for  the  three  models  of  the  F-111.  Finally,  arxl  most 
significant,  is  the  overall  high  performance  confidence  factor  that  the  updated  OFP 
will  meet  the  system  requirements. 

In  addition  to  the  F-111  OFP  maintenance  savings,  certain  indirect  sanngs 
will  result  from  use  of  a dynamic  simulator.  These  savings  will  result  from  a 
reduced  number  of  anomalies  experienced  inflight  that  arc  not  identifiable  in  static 
ground  test.  This  type  of  problem  results  in  "retest  OK"  and  "cannot  duplicate" 
maintenance  actions. 


5-60 


■ 


I 


Table  5-6.  F-lllI)  Oi-)craUonal  Program  Update  Comjmrison 


Without  Simulator 

With  Simulator 

OFP 

OFP 

Performance 

Performance 

Cost 

Confidence 

Cost 

Confidence 

Task  (Man-Months) 

Schedule 

Factor 

(Man-Months) 

Schedule 

Factor 

A] 

> 33  MM 

Phase  1 

Low 

23  MM 

1 Month 

High 

B 

2 Months 

c' 

D 

> 17  MM 

Phase  2 

Medium 

15  MM 

1-1/2 

Medium 

3 Months 

Month 

h| 

^ 33  MM 

Phase  3 

Low 

17  MM 

1 Month 

High 

I 

2 Months 

K 

40  Sorties 

Phase  4 

Medium 

5 Sorties 

1/2 

High 

2 Months 

Month 

$560K 

$70K 

Total  83  MM 

9 Months 

Medium 

55  MM 

4 Months 

High 

ti 

& 

$560K 

$70K 

Valid  cost  comparisons  are  difficult  to  make  because  the  results  are  very 
dependent  upon  the  accuracy  of  the  assumptions.  Autonelics  has  made  a comparison 
of  potential  flight  test  cost,  with  and  without  a simulator,  using  the  following 
assumptions: 

1.  Ground  test  cost  will  not  change  except  for  the  simulator  acquisition  cost, 
estimated  to  be  Sl.O  million. 

2.  Average  cost  of  a test  flight  is  $14,  000. 
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3.  Both  SMAMA  and  the  operating;  commands  would  bo  conducting  flight  test. 
This  cordilion  is  simiJar  to  the  existing  situation  wherein  both  GD-FW  and 
TAC/SAC  arc  flight  testing  tapes. 


Figure  5-lD  presents  fli;'lit  test  cost  through  a 10-year  program  with  the  number 
of  flights  required  for  verification  as  a parameter.  The  base  condition  (no  simulator) 
considers  that  S.^L^.^IA  will  require  six  llights  to  verify  each  tape  and  that  TAC/SAC 
will  require  30  for  the  F-lllU  and  ten  each  for  the  F-lllF  and  FR-lllA.  As  noted 
previously,  40  flights  are  presently  being  conducted  at  Cannon  AFB  for  the  current 
F-lllD  tape  verification.  The  alternate  conditions  with  a simulator  assume  the 
reduced  number  of  verification  flights  shown  on  the  Figure  and  represent  what  are 
felt  to  be  realistic  extremes.  It  should  be  noted  that  the  annual  operating  cost  with 
simulator  is  the  same  as  the  base  condition  until  the  simulator  becomes  operational. 
The  simulator  acquisition  cost  is  additive  and  results  in  a cost  ''break-even"  point 
between  the  third  and  fourth  years  dependent  upon  number  of  flights  required. 

5.  6.  3 Personnel/Equipment  Use 

Simulation/dynamic  testing  will  provide  for  a more  efficient  use  of  Air  Force 
personnel  and  equipment.  AFLC/SMAMA  personnel  can  concentrate  on  the  develop- 
ment of  F-111  software  and  system  level  expertise  that  presently  docs  not  exist  in  the 
Air  Force.  Operational  commands  will  be  left  free  to  concentrate  on  normal  hardware 
support  and  operational  readiness  efforts.  The  more  efficient  use  of  personnel  and 
equipment  will  result  from  deletion  of  extensive  software  development  flight  tests  by 
operational  commands.  The  need  for  an  extensive  weapon  delivery  flight  test  pro- 
gram, with  live  ordnances  and  the  associated  support  personnel  and  eijuipment,  will 
be  eliminated.  The  present  iterative  process  of  software  problem  sohing  using  exist- 
ing static  test  facilities  and  operational  flight  tests  results  in  increased  program 
costs  and  reduced  operational  effectiveness  for  the  FB-lllA,  F-lllD  and  F-111  F 
weapon  systems. 

Little  knowledge  presently  exists  within  SMAMA  or  the  cperational  commands 
Into  the  details  of  the  individual  subprograms  and  the  rationale  behind  tlieir  develop- 
ment. Incorporation  of  changes  to  F-111  computer  flight  programs  requires  an 
intimate  knowledge  of  system  mechanization  requirements  and  the  methods  of  soft- 
ware implementation.  Problem  solution  development,  even  when  performed  by 
contractor  personnel  who  have  intimate  knowledge  of  the  requirements  and  past 
de\ei(pment  history,  is  difficult  and  time  consuming  in  the  complex  areas  of  weapon 
deliver/,  navigation  and  filler  computations.  In  addition,  the  task  of  changing  F-111 
r.ghi  prf>grams  is  being  greatly  aggravated  by  the  high  degree  of  computer  program 
imlzatioas  iwcessary  to  meet  the  constraints  imposed  by  computer  memory  size 
•*r'  available  c>cle  times.  The  recommended  F-111  avionic  simulator/djTiamic  test 
i*v  will  prfivide  the  required  degree  of  F-111  software  visibility  necessary  for 
' \IA  to  become  proficient  in  the  software  maintenance.  Failure  to  obtain 
j will  result  in  a long  and  costly  learning  cycle  with  F-111  .software 
• ng  periormed  by  a trial  and  error  type  procedure  using  static  test 
- * » ..  n.iive  flight  testing. 

' *hr  rci|ulrements  for  extensive  flight  testing  by  the  operational 
.11,  reduce  cht*  required  personnel  and  equipment.  A current 
il  Might  pp)gram  validation  effort  can  be  seen  by  the  afore- 
ghi  teat  eflorts  at  Cannon  AFB.  Air  Force  planning  for  the 
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validation  of  the  i-ccenth'  received  "final"  F-lllD  operational  flight  program  (tape 
D07  lld/215)  includes  40  sorties,  the  use  of  three  aircraft  fi  om  the  operational  ving, 
the  tie-up  of  three  operational  test  and  evaluation  (OTt.  11)  aircr;tit,  three  wing  crews, 
one  OTtF  crew  and  is  expected  to  span  one  to  two  months  calendar  time.  Lxperier.ce 
indicates  that  when  this  effort  is  complete,  however  thoroughly  it  is  performed, 
numerous  uncertainties  in  the  ri'adiness  of  the  weapon  system  will  still  remain.  The 
flight  test  crew  in  an  uncontrolled  environment  can  do  no  more  than  identify  the  icp  of 
"problem  iceberg,  " so  to  speak.  Testing  under  controlled  conditions  with  extensive 
program  sequence  visibility  and  data  recording  is  necessary  to  isolate  subtle  pro- 
grammirig  and  system  problems.  The  dynamic  simulator  approach  as  outlined  in  this 
study  is  the  most  practical  and  cost  effective  means  of  meeting  the  Fli-lllA,  F-lllD 
and  F-lllF  system  maintenance  requirements. 

5.  6.  4 Operational  Capability 

Perhaps  the  most  important  advantage  offered  by  a simulation/d jTiamic  test 
facility  is  the  improvement  in  operational  readiness  and  weapon  system  accuracy. 
Many  people  fail  to  realize  that  the  F-111  computer  software  system  must  be  cv.alu- 
ated,  tested  and  maintained  just  as  thoroughly  as  the  actual  system  hardware.  The 
comple.xity  of  the  F-111  avionic  system  necessitates  the  need  for  a critical  and  quanti- 
tative evaluation  of  its  software  performance.  With  the  existing  static  test  facilities, 
validation  of  software  accuracy  and  operational  effectiveness  cannot  be  obtained  even 
with  an  inordinate  amount  of  operational  flight  testing.  During  flight  tests,  the  soit- 
ware  program  inputs  cannot  be  controlled.  Interpretation  of  relevant  results  is  com- 
plicated by  stochastic  environmental  variables.  The  proposed  simulation  facility 
would  enable  control  of  input  signals  and  test  conditions.  Weapon  delivery  aivl 
navigational  program  sensitivities  to  individual  error  factors  could  he  observed  and 
analyzed.  Complex  weapon  delivery  and  navigational  flight  programs  could  be  opti- 
mized by  repeated  simulated  flights  under  controlled  conditions.  However,  the 
degree  of  operational  improvements  obtainable  with  this  facility  is  diificuli  to  quantify. 
Considering  the  severe  te.st  limitations  imposed  by  the  present  facilities,  the  unco.n- 
trolled  nature  of  flight  tests  and  the  present  iterative  process  of  problem  solving,  the 
expected  improvements  in  F-111  operational  capabilities  would  be  significant. 
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6.  RECOMMENDATIONS  AND  CONCLUSIONS 

G.  1 CrNKUAL 

Hast'd  upon  tlu'  areas  investi^^ated  and  the  results  obtained,  it  is  concluded 
that  SMAMA  has  a real  need  for  a dij^ital  simulation  and  integration  test  facility  of 
the  tjpe  defined  in  this  report.  It  is  noted,  however,  that  this  capability  of  and  by 
itself  is  not  the  eompletc  answer  to  SMAMA's  problem.  Along  with  the  described 
facilitj’  and  the  ITK,  a cadre  of  competent,  dedicated  personnel  who  have  detailed 
F-111  software  problem  solving  experience  should  be  developed  as  soon  as  possible 
to  round-out  this  capability. 

As  time  passes,  knowledgeable  F-111  contractor  support  is  becoming 
increasingly  difficult  to  obtain.  SMAMA  should  consider  this  factor  in  planning 
future  areas  of  contractor  involvement  and  the  efficiency  e:qjected  from  that 
involvement. 

Autonetics  recommends  that  SMAMA: 

1.  Complete  the  upgrading/calibration  of  the  ITE  and  get  qualified  software 
personnel  actively  involved,  full  time,  in  detailed  examination  of  F-111 
OFP  status,  problems  and  optimization.  This  effort  will  serve  the 
immediate  purpose  of  on-going  system  support  as  well  as  being  a training 
ground  that  will  enable  future,  more  comprehensive  OFP  work  on  all 
three  F-111  systems. 

2.  Partition  the  work'  required  to  obtain  the  improved  capability  descril)ed 
herein  and  set  out  to  implement  that  work  through  coml)int'd  S.MAM.A  and 
contractor  efforts  as  soon  as  possible.  Such  eflort  will  include: 

a.  Concentrated  search  throughout  the  government  agencies  for  appli- 
cable base  software  models;  acquisition  of  those  models  and  examina- 
tion of  their  applicability  to  the  F-111  use.  These  models  would 
encompass  off-line  data  reduction  and  analysis  capability  in  addition 
to  the  simulation  models. 

b.  Acquisition  of  CMAC  design  details  from  NWC,  China  Lake,  and 
fabrication  of  initial  unit. 

c.  Search  for  possible  alternate  test/simultaion  processor  and  peripheral 
supplier,  and  trade-off  these  alternates  against  the  baseline  presented 
herein.  Place  orders  for  selected  equipment.  (Processor  equipment 
delivery  could  constitute  the  limiting  schedule  factor). 

d.  Conduct  of  detailed  design  requirements  study/definition  for  the  F-111 
unique  interface  equipment  (lODM  Unit  and  SAS  Unit)  followed  by  initia- 
tion of  design/fabrication  of  these  units. 

e.  Firmly  bounding  all  of  the  software  models/submodels  based  upon  this 
study  and  the  results  of  "a"  and  "c"  above,  and  initiation  of  soffware 
preparation/acquisition  and/or  modification. 
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